Community
Participate
Working Groups
ResourceManager is not thread safe. If you create and dispose the same resources from multiple threads, the reference counting and disposal of resources will not be properly maintained. This can result in duplicates, or in resource being disposed while they are still in use. The use case is a background job that generates thumbnails of diagrams. Also, convenience method JFaceResources.getResources() throws an exception when called from a non-UI thread. Please use Display.getDefault() when getCurrent() returns null.
JFaceResources.getResources() states that it may only be called from the UI thread. In general, the UI classes are not considered thread-safe unless explicitly documented as such, so I'm marking this as an enhancement request. In the meantime, you'll need to sync your calls with the UI...
OK, the JFaceResources convenience method is documented. That's not really the meat of this bug, which is about ResourceManager, and it's API/behavior. The problem is that: 1) Obtaining shared resources from a background thread is valid and useful and 2) It *appears* to currently work. There is no need to call syncExec. But, inspection of the implementation reveals that there will be very rare, random bugs due to multi-threading issues. As far as "UI classes are not considered thread-safe", I don't really know where that's documented, or what is consider a UI class. There are lots of uses of ImageDescriptor from non-UI threads.
SWT is not Thread safe - most SWT calls (unless specified otherwise) must be made in the UI Thread. Jface has the same implication - if we don't say it is Thread safe it is implied that it isn't.
from Platform Plug-in Developer Guide>Standard Widget Toolkit>Threading Issues "Likewise, a platform UI library should not be considered thread-safe unless it is specifically documented as such. Note that most platform UI classes dispatch listeners from the calling thread that triggered the event. Workbench and JFace API calls do not check that the caller is executing in the UI thread.This means that your plug-in may introduce a problem if you call a method that triggers an event from a non-UI thread. SWT triggers an SWTException for all API calls made from a non-UI thread. In general, avoid calling platform UI code from another thread unless the javadoc specifically allows it." The safe workaround for using all platform UI classes from a background thread when thread safety is not promised is to sync the use of the classes through the Display. If you feel strongly that this feature needs high priority, you can vote, provide use cases, etc...to bump up the priority. Changing severity back to "enhancement."
(In reply to comment #3) > SWT is not Thread safe - most SWT calls (unless specified otherwise) must be > made in the UI Thread. True ... but, we're talking about two unrelated things. Some SWT API must be called from the thread associated with a certain Display. But ... that isn't the same as thread-safe. Example: reading and writing to ImageData is not thread-safe. I don't think SWT is thread-safe anywhere, except as a side-effect of the API (for example, Display#getDefault()). Something more similar to this registry/cache might be Platform.getBundle(String), which is thread-safe (and coincidentally, undocumented ;-) ;-). I would like to load images and fonts in a background job so that I can generate thumbnail images in a background job. Conceeded, this is an enhancement. My only concern is that clients assume this support exists already, because there is no exception of any kind when doing this today.
This message is part of a mass update...the bug is likely legitimate, but not a priority. Marking P5. Patches would be entertained.
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
