Community
Participate
Working Groups
Support background activities. In Eclipse 2.0 and 2.1, certain operations like builds and searches always run synchronously and block the user at the UI from doing work until the build has completed. The Eclipse Platform should support operations running asynchronously in the background, so that the user is not forced to be entirely idle while long-running operations are in progress. [Platform UI, Platform Core, Platform Text, JDT Core, JDT UI, PDE] [Theme: Responsive UI]
I've a clarifying sentence to the end: "This will likely require an improved concurrency architecture with more explicit rules."
I have created a branch on org.eclipse.core.resources and org.eclipse.core.runtime for this work. I will start with the initial work in runtime, although I don't know yet if that will be its final resting place. The branch tag is "Bug_36957", and the root version is "Root_Bug_36957".
Changed plan item title to "Support concurrent activities".
*** Bug 38219 has been marked as a duplicate of this bug. ***
I have made a documentation home for this bug report here: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core-home/plan_concurrency.html This page currently contains an overview document that describes the problems and outlines our plan for a solution.
Off of the UI team's development resources page, the Proposals page now has a link to the Core team's page for this activity.
Following on from the job handling released by Core in M1 the UI team has released further support for the Job framework in the UI. It is now possible to create an instance of UIJob which will run in the UI Thread rather than in some other Thread supplied by the JobManager. This is a requirement for any code that must interact with an SWT component. UIJob requires a Display to be able to run as it is run using an asynchExec. This Display must be set before the UIJob is scheduled. If a UIJob is used then the creator of the UIJob must also set the display to run it in and be sure that that display exists when the code is executed. An alternative to UIJob is the WorkbenchUIJob which will get a display from a WorkbenchWindow if one is not set.WorkbenchUIJob is defined in the org.eclipse.ui.workbench project and so it can be used by plugins with org.eclipse.ui.workbench as a prerequisite. The first cut of the progress indicator is now also available. It is disabled by default. You can enable it by adding the line org.eclipse.ui.workbench/showProgressIndicator=true to the file plugin_customization.ini in org.eclipse.platform.
I have added a document to the documentation page (see comment #5) about proposed changes to resource change listeners and auto-build. This page also contains a patch that can be applied on top of 3.0 M2 that moves auto-build into a background thread with progress via the progress view. Use at your own risk ;)
What is the relationship of this proposal to JSR-166? http://www.jcp.org/en/jsr/detail?id=166 JSR-166 seems to be based on Doug Leas concurrency library http://gee.cs.oswego.edu/dl/concurrency-interest/index.html http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html Part of this library is described in Doug Lea "Concurrent Programming in Java: Design principles and patterns": http://gee.cs.oswego.edu/dl/cpj/ http://www.awprofessional.com/catalog/product.asp?product_id={3BADE5EF-2784- 48BF-ADB3-20E1898A26C0} Is there any overlap between JSR-166 and the new eclipse concurrent activities? Is there no relation between the two, because JSR-166 tries to solve a totally different problem? Or can both solutions be used in parallel because they don't impact each other? [I was looking for JSR-166 in bugzilla and on the eclipe websibe (including the mailing lists) and I could not find any reference, therefore I ask this here. The closest I could get was Doug Lea being mentioned in http://dev.eclipse.org/newslists/news.eclipse.tools/msg10329.html] Michael
There is some overlap in functionality between JSR-166 and the support that is being added for this plan item, but there is no formal relationship between the two. I have tried to implement the low level Eclipse concurrency API in a way that will allow us to replace our implementation with the one from the JSR when it becomes available, but realistically that is several years away. The work in Eclipse goes far outside the scope of JSR-166 in dealing with look and feel and user exerience in a GUI-based concurrent application.
For those interested in following progress, see the documentation link in comment #5. New documents have been added to capture recent design discussions about UI presentation and other miscellaneous outstanding issues.
I am going to mark this as fixed as we have added all of the support in core and ui that we plan to for 3.0. Specific problems can be addressed in other problem reports.
One final comment on this plan item: the page mentioned in comment #5 will continue to be updated as we write more documentation, articles, and examples on concurrency and responsiveness. I have just added slides from my talk at EclipseCon 2004 to this page, and there is also an examples plug-in that demonstrates many of the capabilities of the concurrency and responsive UI infrastructure. If anyone in the community writes articles, demos, or other doc in this area I would be happy to link it to that page.
Marking as closed.
