Community
Participate
Working Groups
Created attachment 156886 [details] patch While ModalContext thread is running, calling thread flushes async display messages. (UI thread == main thread). If redo stack is flashed from the ModalContext thread then if there are actions updated asynchronously and some synchronously, then the async updates would happen on the caller thread at the same time as sync updates on the ModalContext thread. When Eclipse's UndoActionHandler is refreshed, it is being refreshed asynchronously and it requires undo-redo lock from the operation history object. The lock however is owned by the ModalContext thread for flushing redo stack. Therefore, undo action handler's refresh is blocked until redo stack is flushing completes. Redo stack flushing cannot complete because GMF AbstractContributionItem can listen to operation history and do an update of the action synchronously, which cannot be done because it is blocked by the main thread flushing scheduled async messages, in this particular case, the undo action handler blocked by the undo-redo lock on operation history. GMF should schedule action updates on the UI thread instead of running them right away.
Delivered for 2.3 - trivial fix. Ran diagram JUnits - all passed. Tested manually - looks good. Note, that Eclipse's UndoActionHandler schedules an async update, so I feel GMF should do the same.
*** Bug 284009 has been marked as a duplicate of this bug. ***
Hooray! The same patch, I gave you six months ago. Thanks for fixing it at last.
Anthony, I would like to commit this patch on 2.2 maintenance and request a new build. Is is possible ?
(In reply to comment #4) > Anthony, > I would like to commit this patch on 2.2 maintenance and request a new build. > Is is possible ? You would want a post 2.2 SR2 build to create a patch? I added the whiteboard "2.2.3 Patch". This would be fine and aligns with the "2.1.4 Patch" stream that the IBM team has been also doing. Ping me back when committed and I will run a build.
(In reply to comment #5) > (In reply to comment #4) > > Anthony, > > I would like to commit this patch on 2.2 maintenance and request a new build. > > Is is possible ? > > You would want a post 2.2 SR2 build to create a patch? I added the whiteboard > "2.2.3 Patch". This would be fine and aligns with the "2.1.4 Patch" stream that > the IBM team has been also doing. > > Ping me back when committed and I will run a build. Thanks Anthony. Committed.
I updated the manifest for org.eclipse.gmf.runtime.common.ui to be version 1.2.3. "3" flagging post 2.2.2. I then released the plugins as version v20100706-0223. Starting a build next.
Added 1.3.3=R2_2_maintenance to the _common.php and ran a cvs update on modeling.eclipse.org so I could start a post GMF 2.2.2 GMF Runtime build. I am not sure if the build version 1.3.3 is actually correct. I know there are 1.3.0 Runtime plugins in SR2. I ran the Runtime build, You can get org.eclipse.gmf.runtime.common.ui_1.2.3.v20100706-0223.jar from http://modeling.eclipse.org/modeling/gmp/gmf-runtime/downloads/drops/1.3.3/I201007061426/gmf-sdk-runtime-I201007061426.zip (the source jar is there too).
[target cleanup] 2.3 M6 was the original target milestone for this bug
[GMF Restructure] Bug 319140 : product GMF and component Runtime Diagram was the original product and component for this bug
