[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[jdt-debug-dev] Fw: Change to behaviour of Job.schedule()
|
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