|
|
| Re: FontNameContributionItem causes deadlock [message #57750 is a reply to message #55813] |
Fri, 29 September 2006 21:32  |
 Cherie Revells
Messages: 299
Registered: July 2009 |
Senior Member |
|
|
Jan,
All reads to the model should be in a runExclusive() in case someone is
in the middle of a write.
Maybe the problem is that if we are not on the UI thread we should be
calling asyncExec() in AbstractContributionItem.historyNotification().
Can you raise a bugzilla against this if you haven't already?
As a workaround, you might be able to build your own toolbar menu in a
different way by providing your own DiagramActionBarContributor. This
is where the call to the Contribution Item Service is called. Other
than that, there is no easy way to remove a contribution that I know of.
Regards,
Cherie
Jan Köhnlein wrote:
> PS:
>
> Any workaround is welcome, especially if it does not require modifying GMF.
>
> I have already tried to register my own DiagramContributionItemProvider
> with a fixed FontNameContributionItem, but I cannot disable the default
> DiagramContributionItemProvider, as the extension point is processed
> with ExecutionStrategy.REVERSE (not FIRST or LAST). As a result, the
> contribution items are doubled and the deadlock is still present.
>
> Thanx in advance
> Jan
>
>
> Jan Köhnlein wrote:
>> We are running a Job in a worker thread that executes commands in the
>> DiagramEditingDomain. As it uses a transaction, the EditingDomin is
>> locked. In the pre-execute phase of the command, an
>> OperationHistoryEvent is fired. The FontNameContributionItem is
>> registered as a listener for these events. In
>> AbstractContributionItem.historyNotification() it tries to execute an
>> update synchronoously on the display thread. So this thread locks the
>> editing domain and tries to access the display thread.
>>
>> At the same time, the UISynchronizer tries to refresh the
>> FontNameContributionItem in the display thread. That one tries to read
>> the font name property using an runExclusive() command in
>> PropertyChangeContributionItem.getPropertyValue(). As the EditingDomain
>> is locked by the worker and the UISynchronizer blocks the display
>> thread, a deadlock occurs.
>>
>> Removing the runExclusive() solves the problem. Is it really necessary
>> to read the values of properties in an exclusive operation?
>>
>> Regards
>> Jan
|
|
|
Powered by
FUDForum. Page generated in 0.03199 seconds
] 
Search
Help
Register
Login
Home
