Community
Participate
Working Groups
Scenario: - Outside client is executing a job on a worker thread. - GMF UI is still enabled while worker thread is executed - potentially causing updates to occur which will ask for a lock of the editing domain. Since transaction is executing on another thread, the UI will lock. - Notifications are received by GMF on the worker thread. - GMF needs to synchronously send the notifications to the UI thread to respect the transaction api contract using the Priveledged runnable. - Synch exec tries to obtain a lock, but UI has lock already --> DEADLOCK... Other Scenario: - Assuming updates are disabled (from above) - transaction executes on worker thread when GMF diagram editor isn't active - User switches to GMF diagram editor while worker thread still executing. - Part activation tries to acquire lock of transaction. - GMF needs to synchronously send the notifications to the UI thread to respect the transaction api contract using the Priveledged runnable. - Synch exec tries to obtain a lock, but UI has lock already --> DEADLOCK...
Couple options available: 1) Make this worker thread case consistent with how the progress meter execution is handled. Disable updates on the UI and continue to handle notifications on the worker thread instead of synchronizing with the main thread. 2) Notify clients and say that these type of Job executions aren't handled by GMF and that they need to synchronize the execution to the main thread before the transaction is executed. Currently exploring a solution with (1) right now..
Created attachment 43914 [details] Patch to disable updates when worker thread is executing Patch removes synchronous handling of notifications due to deadlock scenarios. Adds a listener to the DiagramEditingDomain that will notify when a transaction is activated and deactivated which triggers the updates to be disabled. Nick / Steph: please try patch in your client code.
Still getting deadlock in progress meter scenario now because TreeEditPart is sending notifications asynchronously. If multiple ones are handled, then the previous one will lock the one after it...
Created attachment 43921 [details] Updated patch including fix for TreeEditPart deadlock issue Removed asyncExec in TreeEditPart and utilized priviledged runnable concept from transaction api.
Deadlock scenarios are still occurring with async since they are executed concurrently on the main thread while the worker thread is running. Had a discussion with the EMFT transaction team and we decided that they will supply an api that will ensure synchonous execution of a runnable to avoid these deadlocking scnearios. Currently waiting for this api... Attached patch is invalid for the time being...
I'll verify this against 145877 and close / duplicate accordingly...
Verified that issue was resolved with 145877. *** This bug has been marked as a duplicate of 145877 ***
wrong duplicate
changed to proper duplicate # *** This bug has been marked as a duplicate of 146341 ***
[target cleanup] 1.0 RC5 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
