Bugzilla – Full Text Bug Listing
| Summary: | [Workbench] AbstractUIPlugin imposes bogus restrictions on thread access to public API | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Randy Hudson <hudsonr> |
| Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P5 | CC: | daniel_megert, francisu, pwebster, remy.suen |
| Version: | 3.6 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | stalebug | ||
|
Description
Randy Hudson
Please see the entry in the Eclipse help under
Platform Plug-in Developer Guide >
Programmer's Guide >
Standard Widget Toolkit >
Threading issues
Unless specified, all processing is assumed to be done on the UI thread.
Again, that entry is invalid. Would you like me to open a separate bugzilla to have the SWT doc fixed? Sorry, I forgot to mark this as invalid. This is essentially the same as the bug 335399. getImageRegistry actually lets you call it from a background thread (if the workbench is running) or from the UI thread. Yet this method isn't thread-safe, which means two or more copies of the registry could be in use. One thread could also receive the registry created by another, which might not have been completely initialized. (In reply to comment #4) > getImageRegistry actually lets you call it from a background thread Well, only because you can do it doesn't mean it is allowed and supported. In general, the *.ui.* code is supposed to run in the UI thread unless specified otherwise. Having said that, the image registry is a good example where it would be handy to call it in the non-UI thread, especially because it's often used when a bundle gets started and this can be triggered from a non-UI thread. (In reply to comment #5) > he *.ui.* code is supposed to run in the UI thread unless specified > otherwise. Having said that, the image registry is a good example where it > would be handy to call it in the non-UI thread, especially because it's often > used when a bundle gets started and this can be triggered from a non-UI thread. I think this is related to some issue that I was working on a year or two ago about allowing images to be obtained though some API. I don't remember the exact issue, but I remember there were possible problems with deadlock in the startup related to requiring the images to be created on the UI thread. When I get some time I will try to find the relevant bug report, but I think relaxing this restriction might have helped that. This bug and the bug 335399 are about the same thing. Which one of those bugs can be closed as duplicate? 335399 Is about the lack thread safety. Once getImageRegistry can be called from background worker threads safely, then this bug is about the current requirement that the workbench be running to do so. I realize that calling Display#getDefault() is dangerous since it might create a Display. So either SWT should provide a similar method that only returns the "default" display iff it already exists, or PlatformUI could allow clients to manage the Display "lifecycle", so that PlatformUI can have a Display even when a workbench is not needed. (In reply to comment #6) > I think this is related to some issue that I was working on a year or two ago > about allowing images to be obtained though some API. I don't remember the > exact issue, but I remember there were possible problems with deadlock in the > startup related to requiring the images to be created on the UI thread. When I > get some time I will try to find the relevant bug report, but I think relaxing > this restriction might have helped that. Indeed, if you need an Image and are forced to do a syncExec to get it, the unnecessary use of syncExec can cause deadlock on some SWT platforms (read GTK). 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. |