[jdt-debug-dev] Fw: Change to behaviour of Job.schedule()

[Darin Wright <Darin_Wright@xxxxxxxxxx>]

Team,

I'm cross-posting this on jdt-debug since we use jobs in many places.

Darin

----- Forwarded by Darin Wright/Ottawa/IBM on 01/09/2004 08:27 AM -----


John Arthorne
01/08/2004 04:56 PM
 
        To:     platform-core-dev@xxxxxxxxxxx
        cc: 
        Subject:        Change to behaviour of Job.schedule()

Based on feedback I have changed the behavior of Job.schedule(). 
Previously, calling schedule() while a job was running would do nothing 
(noop).  Now, calling Job.schedule() while a job is running will flag it 
to be rescheduled as soon as it completes.  If you are currently using 
jobs, you will be affected by this change if you were assuming that 
calling schedule() on a running job was a no-op. From my knowledge of 
existing jobs I don't see any culprits that are affected.  See the javadoc 
of Job#schedule for all the fine print.

Part of the motivation for this change is that it is now trivial to 
implement a repeating job (which is a common pattern that people 
previously implemented using a job change listener).  This example runs a 
job ten times (with a delay period of 100 milliseconds):

int count = 0;
final int REPEATS = 10;
Job job = new Job("testRescheduleRepeat") {
        protected IStatus run(IProgressMonitor monitor) {
                count++;
                schedule(100);
                return Status.OK_STATUS;
        }
        public boolean shouldSchedule() {
                return count < REPEATS;
        }
};
job.schedule();

The advantage of putting the loop termination condition in shouldSchedule 
is that it avoids possible timing problems.  Let's say you did this 
instead:

protected IStatus run(IProgressMonitor monitor) {
        if (count++ < REPEATS)
                schedule();
        return Status.OK_STATUS;
}

In a less trivial example, the rescheduling condition may change between 
the time it is tested and the time the run method exits.  For example, 
your job may process a queue until empty, and then return.  The method 
adding elements to the queue would schedule the job if the queue wasn't 
empty and the job wasn't running.  If the job is still running, but has 
already tested its termination condition, then items get added to the 
queue without any job to process them. Using the new schedule() 
functionality, you can simply call schedule() every time an element is 
added to the queue. If a job is already running, it will be flagged for 
rescheduling.  The shouldSchedule method would return false if the queue 
is empty.

If you have comments, suggestions, or concerns about this change, please 
comment in the following bug report:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=41794