| Concurrency contract of UI services (Eclipse 3.6.1) [message #666163] |
Tue, 19 April 2011 07:25  |
Eclipse User |
|
|
|
We recently observed in our RCP program that ones in a while we get the
log entry from org.eclipse.ui.internal.services.WorkbenchServiceRegistry
due to the invocation of the loadFromRegistry method:
"Factory already exists for xxxx"
It turned out that this happened, when two different Eclipse jobs
(non-UI Jobs) accessed getSite().getService() from two different views
attempting to get the corresponding service class xxxx at the same time.
We tried to find out whether this was a violation of a user-contract to
work this way with the UI services API, but we could not find a clear
contract in regard to concurrency issues, in particular neither
getSite() nor getService() did provide corresponding constraints. I
might have simply overlooked it, so apologize if this has happened. But
if there is no concurrency contract, this should either be stated
clearly somewhere or the service API would probably expected to be
thread-safe.
I would appreciate any comments before I decide to open a bug report for
this.
Thanks & Greetings from Bremen,
Daniel Krügler
|
|
|
|
| Re: Concurrency contract of UI services (Eclipse 3.6.1) [message #666184 is a reply to message #666176] |
Tue, 19 April 2011 08:18  |
| Eclipse User |
|
|
|
On 2011-04-19 14:04, Paul Webster wrote:
> The UI services must all be accessed on the UI thread, unless otherwise
> specified.
Where can this contract be found? I searched for it, but I could not
find it. Just the fact, that it is named UI services is not convincing
to me.
> With a few minor exceptions, almost all of our functionality
> accessed through parts or the window are not protected against
> multi-threaded access (as they're all UI related).
Don't you think that this should be documented? Please note that I'm not
asking for a IMenuService or any Eclipse-provided service to be
accessible from all threads, I'm asking whether my own services provided
via the UI services extension point to be thread-safe. My implementation
*within* the create-method of the AbstractServiceFactory *is*
thread-safe, so the limiting factor is the extension point infra
structure. I studied the contract of AbstractServiceFactory,
IServiceWithSources, IServiceLocator, and IDisposable, as well as the
description of the org.eclipse.ui.services extension point and no
constraints about concurrency is provided. If the intention is, that
getService must be called from within the UI thread, that should be
documented.
> We do sometimes make a case for specific pieces of the workbench to be
> thread-safe, like if you were using WorkbenchServiceRegistry to load
> non-UI related services. Although there would probably be implications
> for IServiceLocator as well.
How can I load non-UI related services from the WorkbenchServiceRegistry?
Thanks for your quick reply,
- Daniel
|
|
|
|
Powered by
FUDForum. Page generated in 0.18530 seconds
Home