Re: [tkined] bug with job command?

Juergen Schoenwaelder (schoenw@ibr.cs.tu-bs.de)
Thu, 2 Dec 1999 10:03:08 +0100

>>>>> Chad Smith writes:

Chad> I'm using scotty2.1.10 and have a small problem (easy
Chad> workaround) with updating a clock on my application. I use the
Chad> job create command to create a timer that updates the clock
Chad> every minute. The problem is when I set the system time
Chad> backwards. The -time configuration option of the job is
Chad> incremented by the number of seconds (it appears) as I set the
Chad> system time back. This causes my clock to not be updated for
Chad> potentially long periods of time, depending on how far back I
Chad> set the time.

Chad> For example, if I set the system time back 1 hour, the -time
Chad> option is incremented by 360000, which means it will take an
Chad> hour before the clock gets updated again.

Chad> My solution is to kill the job and restart it whenever the
Chad> system time is changed, but that won't work if an admin changes
Chad> it on the command line (the GUI provides an interface for
Chad> setting the time). So my question is, is this a bug with scotty
Chad> or is it a known "that's what it's supposed to do" problem? If
Chad> it's a bug, any simple way I can fix it in the release that I'm
Chad> using?

Never thought about this one before. There are actually two problems
here.

The first problem is in tnmJob.c function AdjustTime() where the
remaining job times are computed. If you clock moves backwards, you
will get a negative value for delta and hence the remaining time will
increase rather than decrease. It is easy to add a check so that the
remaining time will not be updated if delta is negative, and this may
make sense.

The second problem is in the Tcl timer handling core. The job command
implementation sets up a timer which triggers when the next job event
needs to be processed by using Tcl_CreateTimerHandler(). This function
takes the offset (in ms) and computes an absolute time value which is
then used by the event loop to actually call back the job command
implementation. This means that the next schedule point will be quite
a bit in the future if you roll back the time after the Tcl timer has
been set up. (And this may be correct in the sense that this is
probably the only way to implement things since you generally will not
be notified of system time changes.)

I think I will put in the patch to address the first problem.

diff -u -r1.9 tnmJob.c
--- tnmJob.c 1999/10/06 09:35:57 1.9
+++ tnmJob.c 1999/12/02 08:47:30
@@ -457,6 +457,15 @@

control->lastTime = currentTime;

+ /*
+ * Do not increase remaining times of any jobs if the clock
+ * has moved backwards.
+ */
+
+ if (delta <= 0) {
+ return;
+ }
+
for (jobPtr = control->jobList; jobPtr; jobPtr = jobPtr->nextPtr) {
if (jobPtr->status != suspended) {
jobPtr->remtime -= delta;

But this will not really give you what you want since:

(a) you need to force a recomputation of the remaining job times in
order to compensate the time change "early"

(b) you need to force a scheduling point (using "job schedule") in
order to compensate the hanging Tcl timer

So the real solution is probably to add text to the manual page that
changing the system clock may have severe effects on job scheduling.
Here is the text that goes into the job(n) man page:

The job scheduler itself relies heavily on the Tcl timer
interface which itself depends on the system clock. Moving
the system clock backwards can have the effect that jobs
are not activated for the amount of time the system clock
was moved backwards. Similarly, moving the system clock
forward can have the effect that jobs are activated ear-
lier for the amount of time the system clock was moved
forward.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<schoenw@ibr.cs.tu-bs.de>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>

--
!! This message is brought to you via the `tkined & scotty' mailing list.
!! Please do not reply to this message to unsubscribe. To subscribe or
!! unsubscribe, send a mail message to <tkined-request@ibr.cs.tu-bs.de>.
!! See http://wwwsnmp.cs.utwente.nl/~schoenw/scotty/ for more information.