|
| Re: [Transactions] Deadlock using WorkspaceSynchronizer.Delegate [message #425386 is a reply to message #425362] |
Mon, 24 November 2008 00:11   |
Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Ömer,
Can you do an asyncExec(...) in your handleResourceChanged(...) instead
of syncExec(...) ?
In general, Eclipse discourages synchronization with the UI thread in a
resource-change listener or, indeed, doing anything else that might
acquire resources (such as locks, incnluding the UI-thread lock) or take
a non-trivial amount of time.
On the subject of lock conflict: are you sure that it is the AcquireJob
that is conflicting? I don't see now it can, as its rule doesn't
intersect with any other. I suspect, rather, that it is simply waiting
for the transaction lock, which is currently held by another thread that
is waiting for a workspace resource.
HTH,
Christian
Ömer Yildiz wrote:
> Hello,
>
> I'm having a problem with the Synchronizer Delegate. In the
> handleResourceChanged() the code reloads the changed resource and calls
> setInput() on an JFace viewer in order to update itself. The viewer uses
> a TransactionalContentPRovider. Now this is where I encounter a
> deadlock. The content provider executes runExclusive(), but the
> execution blocks in org.eclipse.emf.transaction.util.Lock:
>
> jobmgr.beginRule(jobRule, null);
> jobRule is an instanceof AcquireRule.
>
> handleResourceChanged() gets called within a ResourceSynchJob whose
> scheduling rule is just a combined rule of all affected resources.
>
> I don't see why the two scheduling jobs are conflicting each other.
>
> The code looks similar to the following:
>
> public boolean handleResourceChanged(Resource resource) {
> // reload resource
>
> Display.getCurrent().syncExec(new Runnable() {
> public void run() {
> viewer.setInput(reloadedInput);
> }
> });
>
> return true;
> }
>
> Any ideas?
>
> Best regards,
> Ömer
|
|
|
|
Powered by
FUDForum. Page generated in 0.02943 seconds
] 
Search
Help
Register
Login
Home
