| FontNameContributionItem causes deadlock [message #55680] |
Tue, 26 September 2006 05:48  |
Eclipse User |
|
|
|
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
|
|
|
|
| Re: FontNameContributionItem causes deadlock [message #57750 is a reply to message #55813] |
Fri, 29 September 2006 17:32  |
| Eclipse User |
|
|
|
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.05811 seconds
Home