Community
Participate
Working Groups
The Jobs API should support a CommonJob to share a common background thread so runnables that should not block the main thread, but are API rich, short lived, and make the Eclipse threading model unnecessarily complex can use.
Created attachment 191800 [details] First Draft Implementation First Draft Implementation. JUnit Test Code Coverage: CommonJob.java: 79.7% CommonJobManager.java: 85.2%
Please refer to the following 15 min presentation to give a perspective on the requirement for this feature: http://www.youtube.com/watch?v=tCeUO-kovFE
Created attachment 192345 [details] New implementation Thanks James for your suggestions. The new implementation: - supports CommonJob.asyncExec() - supports CommonJob.getThread(), which returns the common thread used for all CommonJobs. - The CommonJobManager now uses a real thread, instead of a Job, so that CommonJobs can rely on a single, identical thread being consistently used for executing code. - Comprehensive java docs JUnit Test Code Coverage: CommonJob.java: 100% CommonJobManager.java: 87.9%
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. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
