<Swing Dev> [9] Review Request for 8030702: Deadlock between subclass of AbstractDocument and UndoManager
Alexander Scherbatiy
alexandr.scherbatiy at oracle.com
Tue Sep 22 13:18:53 UTC 2015
On 9/21/2015 12:19 PM, Semyon Sadetsky wrote:
>
>
> On 9/21/2015 11:27 AM, Alexandr Scherbatiy wrote:
>> 18.09.2015 19:22, Semyon Sadetsky пишет:
>>>
>>>
>>> On 9/18/2015 6:51 PM, Alexander Scherbatiy wrote:
>>>> On 9/16/2015 5:14 PM, Semyon Sadetsky wrote:
>>>>>
>>>>>
>>>>> On 9/16/2015 1:38 PM, Alexander Scherbatiy wrote:
>>>>>> On 9/15/2015 10:37 PM, Semyon Sadetsky wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 9/15/2015 6:16 PM, Alexander Scherbatiy wrote:
>>>>>>>> On 9/11/2015 7:24 PM, Semyon Sadetsky wrote:
>>>>>>>>>
>>>>>>>>
>>>>>>>> The deadlock that you described exists only because
>>>>>>>> AbstractDocument uses locks in the UndoableEdit.undo()/redo()
>>>>>>>> methods.
>>>>>>>> Applications that use UndoManager and do not use lock in the
>>>>>>>> UndoableEdit.undo()/redo() methods do not have deadlock. They
>>>>>>>> worked fine before the fix and can lost data consistency after
>>>>>>>> the fix. This is definitely the regression.
>>>>>>> You mean scenario when a document that does not support
>>>>>>> synchronization but anyway is modified from several threads.
>>>>>>> You can expect that such scenario is functional only if such
>>>>>>> document is a single atomic field.
>>>>>>> I updated the fix
>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8030702/webrev.04/ take it
>>>>>>> into account.
>>>>>>
>>>>>> This looks better. There are just some comments:
>>>>>> - The 'inProgress' variable in
>>>>>> UndoManager.undo()/redo()/undoOrRedo() methods should have
>>>>>> synchronization.
>>>>>> Is it possible to move 'if (inProgress)' check into
>>>>>> tryUndoOrRedo() method similarly to as it was used in the version
>>>>>> 2 of the fix?
>>>>>> - UndoManager line 489: why not to use the original check from
>>>>>> the undoOrRedo() method "if (indexOfNextAdd == edits.size())" to
>>>>>> pick up undo or redo action?
>>>>>> - UndoManager line 516: An undoable edit can be requested two
>>>>>> times for the ANY action because the 'undo' variable can have old
>>>>>> value in the second synchronized block.
>>>>>> Even the logic is right it is better to take an edit based
>>>>>> on the 'action' variable.
>>>>>> - UndoManager.undoOrRedo() throws CannotUndoException now
>>>>>> instead of CannotRedoException if the redo action is not possible.
>>>>>> - It is possible to get rid of the 'done ' variable in
>>>>>> UndoManager.tryUndoOrRedo() just simply have an infinity loop.
>>>>>> - It is possible to use Boolean values TRUE, FALSE or null for
>>>>>> three-state logic. But it is up to you to choose enums or Boolean
>>>>>> in the fix.
>>>>>>
>>>>> I made the changes:
>>>>> http://cr.openjdk.java.net/~ssadetsky/8030702/webrev.05/ except
>>>>> for the last one. Actually triple Boolean logic is a bad style.
>>>>
>>>>
>>>> There are two main synchronized block in the tryUndoOrRedo()
>>>> method: one to look up an undoable edit lock and the second which
>>>> use the undoable edit lock.
>>>> In the version 02 of the fix the original code from undo() and
>>>> redo() methods were moved to these two blocks.
>>>> It is not clear why don't you want to do the same (just call
>>>> tryUndoOrRedo() with necessary argument for all
>>>> UndoManager.undo()/redo()/undoOrRedo() methods) in the latest fix?
>>>>
>>>> Splitting logic like:
>>>> -------------------
>>>> 420 public void undo() throws CannotUndoException {
>>>> 421 if (!tryUndoOrRedo(Action.UNDO)) {
>>>> 422 synchronized (this) {
>>>> 423 super.undo();
>>>> 424 }
>>>> 425 }
>>>> 426 }
>>>> -------------------
>>>> always have a question that before the fix the super.undo() was
>>>> called only for '!inProgress' condition but now the 'inProgress'
>>>> can be changed when super.undo() is called.
>>>>
>>> inProgress can be changed when super.undo() is called because it is
>>> protected by synchronized block.
>>> Imagine that undo() is called with inProgress = true, then it is
>>> blocked by the concurrent document change, and after the retry it
>>> finds inProgress= false, so it cannot undo by usual way anymore,
>>> because the UndoManager is converted into a single edit and it
>>> should undo using super.undo().
>>
>> I am talking about slightly different thing.
>> This is the code for the undo() method before the fix.
>> -------------------
>> 410 public synchronized void undo() throws CannotUndoException {
>> 411 if (inProgress) {
>> 412 UndoableEdit edit = editToBeUndone();
>> ...
>> 416 undoTo(edit);
>> 417 } else {
>> 418 super.undo();
>> 419 }
>> 420 }
>> -------------------
>>
>> Checking the 'inProgress' variable and calling undoTo(edit) and
>> super.undo() is done under the same synchronized block.
>>
>> Let's slightly modify the code:
>> -------------------
>> public void undo() throws CannotUndoException {
>>
>> boolean res = true;
>>
>> synchronized (this) {
>> if (inProgress) {
>> UndoableEdit edit = editToBeUndone();
>> ...
>> undoTo(edit);
> It is not possible to execute undoTo() here because it will cause the
> deadlock we are trying to fix.
May be with the updated sample it would be cleaner.
This is just a some method which uses a synchronization:
----------------------
public synchronized void someMethod() {
if (inProgress) {
// do something
} else {
// do something else
}
}
----------------------
This is an updated method:
-------------------
public void someMethod() {
boolean res = true;
[some synchronization]
if (inProgress) {
// do something
} else {
res = false;
}
[end of some synchronization]
[some synchronization]
if (!res) {
do something else
}
[end of some synchronization]
}
-------------------
The problem with the updated method is that inProgress variable can
have a value different from 'res' and the 'do something else' action can
be executed even inProgress is true.
>> } else {
>> res = false;
>> }
>> }
>>
>> synchronized (this) {
>> if (!res) {
>> super.undo();
>> }
>> }
>> }
>> -------------------
>>
>> Now the 'inProgress' variable checking and undoTo() is done on the
>> first synchronized block.
>> The result of the inProgress is used in the second synchronized
>> block. But the 'inProgress' variable
>> can be changed between these two blocks and we can't relay on the
>> 'res' value.
>> Instead of 'res' the original 'inProgress' value should be checked
>> in the second synchronized block and if it is true the undoTo(edit)
>> should be called again instead of super.undo().
>>
> Above you provided the code logic bore the fix which is reworked
> because it does not work. Why do we need to discuss it?
We need to discuss this because the inProgress variable in your
latest fix is used exactly as in the provided sample.
UndoManager line: 473 tryUndoOrRedo(action) returns false if
inProgress is false.
UndoManager line: 422 super.undo() is called if
tryUndoOrRedo(action) returns false despite the real 'inProgress'
variable value.
Thanks,
Alexandr.
>>
>> Thanks,
>> Alexandr.
>>
>>>> Thanks,
>>>> Alexandr.
>>>>
>>>>>> Thanks,
>>>>>> Alexandr.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Alexandr.
>>>>>>>>>> Thanks,
>>>>>>>>>> Alexandr.
>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>> Also synchronization is needed to provide coherency with
>>>>>>>>>>>>> the state of the document. If those two are not provided
>>>>>>>>>>>>> the document can be corrupted. This is enough most usages.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>> It is
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I still think that updating the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoableManager for one particular
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> AbstarctManager class can be made only
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> after investigation of other possibilities.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You could start with choosing behavior
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which you want to achieve or to keep, like:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - fix the deadlock
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - atomic undo() method
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - serialization
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - immediate roll back action
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - abstract document consistency after
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> undo() action
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - ...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We need to pay attention to the deadlock
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> at first of cause.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Serialization and consistency are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> achieved. Any concrete doubts?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> immediate roll back action -- ?what is that?
>>>>>>>>>>>>>>>>>>>>>>>>>>>> "if user starts a long edit operation
>>>>>>>>>>>>>>>>>>>>>>>>>>>> and press undo after that he expects when
>>>>>>>>>>>>>>>>>>>>>>>>>>>> the long edit is finished it will be rolled
>>>>>>>>>>>>>>>>>>>>>>>>>>>> back immediately." - what ever does it mean.
>>>>>>>>>>>>>>>>>>>>>>>>>>> Got it. It will work within the fairness. We
>>>>>>>>>>>>>>>>>>>>>>>>>>> have discussed this allready.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I sacrificed undo/redo call atomicity
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> because you did not like doc references in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> undo manager. I think it is not important
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for the most multithreaded undo/redo
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> scenarios.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Could you give more details about it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Which doc references do you mean?
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Your statement a dozen iterations ago was:
>>>>>>>>>>>>>>>>>>>>>>>>>>> "There should be a way to solve these
>>>>>>>>>>>>>>>>>>>>>>>>>>> problems without storing links of external
>>>>>>>>>>>>>>>>>>>>>>>>>>> classes inside the UndoManager."
>>>>>>>>>>>>>>>>>>>>>>>>>>> I guess you used "link" term for references.
>>>>>>>>>>>>>>>>>>>>>>>>>>> I would recommend to use standard
>>>>>>>>>>>>>>>>>>>>>>>>>>> terminology: reference to the object,
>>>>>>>>>>>>>>>>>>>>>>>>>>> dependency on the class, etc... to avoid
>>>>>>>>>>>>>>>>>>>>>>>>>>> misunderstanding.
>>>>>>>>>>>>>>>>>>>>>>>>>>> Usually "link" is in a browser document or a
>>>>>>>>>>>>>>>>>>>>>>>>>>> tool that produces executables after
>>>>>>>>>>>>>>>>>>>>>>>>>>> compilation.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and look which of the following
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> approaches can better solve them (where
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the fist is more preferred and the last
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is less preferred case):
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - using UndoManager as is without
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> adding links from some specific classes
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - provide an API for UndoManager to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> work with UndoableEdit-s which have
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> synchronization for undo/redo methods
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - adding links of external classes
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> directly to UndoManager
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> What do you mean under link term? A
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reference or dependency?
>>>>>>>>>>>>>>>>>>>>>>>>>>>> There are two options. If UndoManager
>>>>>>>>>>>>>>>>>>>>>>>>>>>> is a class designed to be only used with
>>>>>>>>>>>>>>>>>>>>>>>>>>>> the AbstractDocument and placed in the
>>>>>>>>>>>>>>>>>>>>>>>>>>>> javax.swing.text package it definitly can
>>>>>>>>>>>>>>>>>>>>>>>>>>>> have special code to handle an abstract
>>>>>>>>>>>>>>>>>>>>>>>>>>>> document instance in a special way.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> If UndoManager is a general purpose
>>>>>>>>>>>>>>>>>>>>>>>>>>>> class, it looks strange that it handles
>>>>>>>>>>>>>>>>>>>>>>>>>>>> some special classes in different way as
>>>>>>>>>>>>>>>>>>>>>>>>>>>> all others. It usually mean that there are
>>>>>>>>>>>>>>>>>>>>>>>>>>>> some design problems in this class. That is
>>>>>>>>>>>>>>>>>>>>>>>>>>>> why I just asked to look at other ways at
>>>>>>>>>>>>>>>>>>>>>>>>>>>> first. Only if other solutions are not
>>>>>>>>>>>>>>>>>>>>>>>>>>>> suitable it has sense to look at the way
>>>>>>>>>>>>>>>>>>>>>>>>>>>> that you are provided.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Correct. I introduced extra dependency. It
>>>>>>>>>>>>>>>>>>>>>>>>>>> is optional, but anyway. Of cause there is a
>>>>>>>>>>>>>>>>>>>>>>>>>>> design problem in undo javax.swing.undo
>>>>>>>>>>>>>>>>>>>>>>>>>>> package. But I cannot rewrite the API
>>>>>>>>>>>>>>>>>>>>>>>>>>> because we will get a compatibility problem
>>>>>>>>>>>>>>>>>>>>>>>>>>> then. I mentioned this several times in this
>>>>>>>>>>>>>>>>>>>>>>>>>>> thread.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We are constrained by compatibility
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> requirements. UndoManager is a broadly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> used class we cannot change the API so
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> drastically.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think that you can generalize your
>>>>>>>>>>>>>>>>>>>>>>>>>>>> solution just adding an internal interface
>>>>>>>>>>>>>>>>>>>>>>>>>>>> like sun.swing.UndoableEditLock.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Every UndoableEdit which implements this
>>>>>>>>>>>>>>>>>>>>>>>>>>>> interface can provide a lock for its
>>>>>>>>>>>>>>>>>>>>>>>>>>>> synchronization.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> If this will work it can be made public
>>>>>>>>>>>>>>>>>>>>>>>>>>>> in some days so other application can also
>>>>>>>>>>>>>>>>>>>>>>>>>>>> have proper synchronization for their
>>>>>>>>>>>>>>>>>>>>>>>>>>>> undo/redo actions.
>>>>>>>>>>>>>>>>>>>>>>>>>>> OK. I added it.
>>>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8030702/webrev.02/
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> - We can return a public class that
>>>>>>>>>>>>>>>>>>>>>>>>>> implements an internal interface, but we
>>>>>>>>>>>>>>>>>>>>>>>>>> can't expose an internal API in the public
>>>>>>>>>>>>>>>>>>>>>>>>>> class definition.
>>>>>>>>>>>>>>>>>>>>>>>>>> May be it is possible to wrap an
>>>>>>>>>>>>>>>>>>>>>>>>>> UndoableEdit to the UndoableEditLockSupport
>>>>>>>>>>>>>>>>>>>>>>>>>> in the UndoableEditEvent or in some other place.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> - The similar code is used both in the
>>>>>>>>>>>>>>>>>>>>>>>>>> UndoManager.undo() and redo() methods. Is it
>>>>>>>>>>>>>>>>>>>>>>>>>> possible to move this code to one method that
>>>>>>>>>>>>>>>>>>>>>>>>>> does undo or redo depending on the given
>>>>>>>>>>>>>>>>>>>>>>>>>> argument?
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> OK. accepted.
>>>>>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ssadetsky/8030702/webrev.03/
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> - UndoManager.undo/redo methods
>>>>>>>>>>>>>>>>>>>>>>>> In your previous fix inProgress variable
>>>>>>>>>>>>>>>>>>>>>>>> and the super call were used under the lock. It
>>>>>>>>>>>>>>>>>>>>>>>> may leads to some synchronization issues if you
>>>>>>>>>>>>>>>>>>>>>>>> decide to omit it.
>>>>>>>>>>>>>>>>>>>>>>>> - UndoManager.tryUndoOrRedo()
>>>>>>>>>>>>>>>>>>>>>>>> It is possible to get rid of 'done'
>>>>>>>>>>>>>>>>>>>>>>>> variable just using an infinity loop and return
>>>>>>>>>>>>>>>>>>>>>>>> the exact result where the loop is terminated.
>>>>>>>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>>>>>>> AbstractDocument.DefaultDocumentEventUndoableWrapper
>>>>>>>>>>>>>>>>>>>>>>>> implements both UndoableEdit and
>>>>>>>>>>>>>>>>>>>>>>>> UndoableEditLockSupport interfaces but
>>>>>>>>>>>>>>>>>>>>>>>> UndoableEditLockSupport already extends
>>>>>>>>>>>>>>>>>>>>>>>> UndoableEdit.
>>>>>>>>>>>>>>>>>>>>>>>> - "@since 1.9" javadoc for
>>>>>>>>>>>>>>>>>>>>>>>> DefaultDocumentEventUndoableWrapper.lockEdit()/unlockEdit()
>>>>>>>>>>>>>>>>>>>>>>>> methods really belongs to the
>>>>>>>>>>>>>>>>>>>>>>>> UndoableEditLockSupport methods.
>>>>>>>>>>>>>>>>>>>>>>>> In this case there is no need for
>>>>>>>>>>>>>>>>>>>>>>>> {@inheritDoc} tag.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "adding links of external classes directly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to UndoManager" - Sorry, did not catch
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> what are you about? Could you clarify?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --Semyon
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --Semyon
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There is a mistake in your scenario
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> steps: fireUndoableEditUpdate() is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> called before the freeing the lock
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (see
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> AbstractDocument.handleInsertString()
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> method).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yet another argument do not do
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> this from the user experience:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if user starts a long edit
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> operation and press undo after
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that he expects when the long
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> edit is finished it will be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> rolled back immediately.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It is not true. The first
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> process adds his undo edit to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the UndoManager. While a user
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> trying to press undo the second
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> long process can be started.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That is what led to this issue
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> because when undo is in progress
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> document writing should be allowed.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sorry but I didn't see why is "It
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not true"? Then what is your
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> expectation when you press undo
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> button while edit is not finished
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> yet and there is no way to abort it?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It would be good if it works
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> as you described. But it does not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> work in this way with or without
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> your fix.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> undo() action has writeLock in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> AbstractDocument and because of it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is always executed after insert
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> string action.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If a user sees that undo is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> available, he can call it but the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> second long insertString process
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can start earlier and acquire the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> writeLock.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> That is what we are going to fix.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> And this does work after this fix.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Undo call will be blocked by the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> long edit until the last is done
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> without any deadlocks. And when
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> edit is done undo() will acquire
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the lock and prevent any new edits
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> until undo() is done. Please
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> provide a scenario when in your
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> opinion it does not wok.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The first process starts for 5
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> minutes. When it is finished a user
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sees that he can press undo. While
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> he is pressing undo button, the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> second long process starts for 10
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> minutes and acquire the write lock.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The user presses undo but he needs
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to wait 10 more minutes until the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> second process is finished.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Actually, if two or more threads are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> waiting for a monitor it is not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> determined which one will get the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> control after the signal. To order
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> that the ReentrantLock API could be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> used but AbstractDocument uses
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wait/notify for locking. I think it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is not worth to dig so deep. It does
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not cause any issues
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The issue that is considered is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "if user starts a long edit operation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and press undo after that he expects
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> when the long edit is finished it will
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be rolled back immediately."
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If you are agree that it is not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> always possible to do the roll back
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "immediately" there is no point to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> discussion.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I agree. On that level it is not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> possible to predict the order exactly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in such scenario. But the state of the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> document will be consistent. And it is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> possible to have it predictable using
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> lock fairness.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> because undo() always get the last
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> edit anyway. If it will be important
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for somebody to preserve the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> execution order on that level of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> details we will fix it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So undo should be executed
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> after the edit is fully
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> performed because the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> corresponding UndoableEdit
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which undos this edit can be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> produced only after the edit is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> done.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think at first we need to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> look on the situation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> externally rather than
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> concentrate on implementation
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> questions like in which class
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> do references go.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes, please look on this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> situation from a user point of
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> view which wants to implement
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simple Java Painter.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But could you describe this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> scenario? Just steps when this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simple Painter fails under the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> proposed fix?I
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Note, if this Painter's content
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> is not an AbstarctDocument it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> will work as before the fix.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Any application that uses
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoManager and wants to have the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> same synchronization (have the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> same lock both for UndoableEdit
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> adding and undo() method
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> execution) will have the same
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> deadlock problems.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> As I have already written:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ---------------
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Consider someone writes Java
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Painter application where it is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> possible to draw lines and images
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and uses UndoManager for undo/redo
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actions.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> He might want that it was
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> possible to work with copied
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> images. He can get lock on ctrl+v
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> action, process an image, prepare
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoableEdit and notify the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoManager.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> He also can use lock/unlock in
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the undo action to have a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> consistent state with the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processed image. If someone calls
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> undo action during the image
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processing and gets a deadlock
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does it mean that link from Java
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Painter need to be added to the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoManager?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ---------------
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Still do not understand the steps
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for your Painter scenario. A link
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (reference?) can be added if it is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> required to implement
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> functionality. If the content is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> not an AbstarctDocument it may be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> required to implement custom
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoManager to support the same
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> behavior.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> What is the difference between
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the AbstractDocument and other
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> classes (in Swing or user defined)?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Do you mean that the UndoManager is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> intended only to be used with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> AbstractDocument and it shouldn't be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> used in other cases where undo/redo
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> actions are required for non text data?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No, undo manager can be used with any
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> classes. But since we have it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> assigned to AbstarctDocument so often
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> we need to do our best to make undo
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> manager working with it correctly
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> because users do not like deadlocks
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> usualy. For other classes we cannot
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> provide synchronization by default
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> because there is no API to get the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> lock. So it remains up to user how to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> provide the undo manager
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> synchronization with the object it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> controls for other classes
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> What we should do just to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> understand that the same deadlock can
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> happen in an user applications because
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> he wants to use the same
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> synchronization both for the data
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processing and for the undo action. If
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> so, there should be two investigations:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1. Is it possible to achieve the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> requested goals without changing
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoManager? In other words The
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoManager should be used in proper
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> way as it is required by its design.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2. Is it possible to update the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoManager API to provide
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> functionality that meets new requests?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> With API change it is reachable. But I
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> would preserve the current API as less
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> constrained. If we add some methods for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> locking we will determine the way how a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> user should synchronize his undoable
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> content. And user may not need any
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> synchronization at all. We should keep
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in mind this opportunity as well.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Only after this discussion there can
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be a reason to look to other ways.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think our undo manager
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> implementation do not pretend to be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> used as the global undo manager for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> big complex applications and it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cannot cover all possible undo
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> approaches. But some basic
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> functionality can be provided and it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> should be usable. Without edits
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> serialization approach it is not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> usable for multithreaded use. So
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> either we do not pretend to provide a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> multithreaded undo manager and remove
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> all synchronize keywords from
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoManager class, either we need to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> support serialization approach which
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> does not cause deadlocks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I don't see a contradiction here,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> could you point on it more precisely?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --Semyon
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --Semyon
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 7/30/2015 5:27 PM,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexander Scherbatiy wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Consider someone writes
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Java Painter application
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> where it is possible to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> draw lines and images and
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> uses UndoManager for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> undo/redo actions.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> He might want that it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> was possible to work with
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> copied images. He can get
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> lock on ctrl+v action,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> process an image, prepare
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoableEdit and notify
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the UndoManager.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> He also can use
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> lock/unlock in the undo
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> action to have a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> consistent state with the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processed image. If
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> someone calls undo action
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> during the image
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> processing and gets a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> deadlock does it mean that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> link from Java Painter
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> need to be added to the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> UndoManager?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It looks like
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> AbstractDocument
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> violates UndoManager
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> synchronization contract
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> when it both use lock to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> work with UndoManager
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and in the implemented
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> undo() method.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Alexandr.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --Semyon
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
More information about the swing-dev
mailing list