views:

372

answers:

2

The Jobs API in Eclipse RCP apparently works much differently than I expected. I thought that creating and scheduling multiple Jobs would actually cause multiple worker threads to be created, executing the Jobs in parallel unless there was an ISchedulingRule conflict.

I went back and read the documentation more closely, and also discovered this comment in the JobManager class:

/**
 * Returns a running or blocked job whose scheduling rule conflicts with the 
 * scheduling rule of the given waiting job.  Returns null if there are no 
 * conflicting jobs.  A job can only run if there are no running jobs and no blocked
 * jobs whose scheduling rule conflicts with its rule.
 */

Now it looks to me like the Job manager will only ever attempt to use one background worker thread. Am I completely wrong about this? If I'm right,

  • what is the point of scheduling rules and locks? If there is only one worker thread, Jobs can never preemt each other. Wouldn't these only ever be used in case a Job's sleep() method is called (e.g. sleeping while holding a Lock)?
  • does any part of the platform allow two Jobs to actually run concurrently, on multiple worker threads, thus making the above features useful somehow?

What am I missing here?

+1  A: 

Take a look at the run method in the documentation, specifically this part:

Jobs can optionally finish their execution asynchronously (in another thread) by returning a result status of ASYNC_FINISH. Jobs that finish asynchronously must specify the execution thread by calling setThread, and must indicate when they are finished by calling the method done.

ASYNC_FINISH there looks interresting.

Per Wiklander
Will the job manager still enforce scheduling rules for jobs that are finishing asynchronously? I would hope that it does (and I assume this is what calling done() helps accomplish) but I'd like to be sure.
Mike Daniels
A: 

This Eclipse Corner article provides good description as well as few code samples for Eclipse Job API. The IJobManager API is only needed for advanced job manipulation, e.g. when you need to use locks, synchronize between several jobs, terminate jobs, etc.

Eugene Kuleshov