#1526 after problems when date is changed

obsolete: 8.3
closed-rejected
5
2004-03-05
2001-06-11
Simon White
No

TCL version is that supplied in TclPro1.4.

Adjusting the system time affects the after event. I
have not checked if the problem also occurs due to
daylight savings.

Code:

proc timer {} {
puts [clock seconds]
after 1000 {timer}
}
timer

Change the date system time (I used date & time
facility of KDE2). Most of the time the above loop
stops printing.

Desired Behaviour:

To be able to change the time and date both via TCL and
the system without the code stopping.

Discussion

  • Simon White

    Simon White - 2001-06-11

    Logged In: YES
    user_id=59929

    After do some further checking the problem is found to be
    with changing the system clock to an earlier time. A future
    time causes all event to trigger immediately. As a result I
    decided to implement the same for past times. This I feel
    is a better solution than the after events hanging for long
    periods of time. Heres the change to
    tcl8.3.2/generic/tclTimer.c:

    --- tclTimer_org.c Fri Apr 16 01:46:54 1999
    +++ tclTimer.c Mon Jun 11 16:56:21 2001
    @@ -112,6 +112,8 @@
    } ThreadSpecificData;

    static Tcl_ThreadDataKey dataKey;
    +/* Keep track of our last TimerCheckProc */
    +static Tcl_Time timeCheck;

    /*
    * Prototypes for procedures referenced only in this file:
    @@ -158,6 +160,7 @@
    tsdPtr = TCL_TSD_INIT(&dataKey);
    Tcl_CreateEventSource(TimerSetupProc, TimerCheckProc,
    NULL);
    Tcl_CreateThreadExitHandler(TimerExitProc, NULL);
    + timeCheck.sec = timeCheck.usec = 0;
    }
    return tsdPtr;
    }
    @@ -402,6 +405,32 @@
    */

    TclpGetTime(&blockTime);
    +
    + do
    + {
    + if (timeCheck.sec < blockTime.sec)
    + break;
    +
    + if (timeCheck.sec == blockTime.sec)
    + {
    + if (timeCheck.usec <= blockTime.usec)
    + break;
    + }
    +
    + /* System clock has been modified to a value in
    the
    + past, trigger all timer events */
    + {
    + TimerHandler *timerHandlerPtr =
    tsdPtr->firstTimerHandlerPtr;
    + do
    + {
    + timerHandlerPtr->time.sec =
    timerHandlerPtr->time.usec = 0;
    + timerHandlerPtr =
    timerHandlerPtr->nextPtr;
    + } while (timerHandlerPtr != NULL);
    + }
    + } while (0);
    + timeCheck.sec = blockTime.sec;
    + timeCheck.usec = blockTime.usec;
    +
    blockTime.sec = tsdPtr->firstTimerHandlerPtr->time.sec -
    blockTime.sec;
    blockTime.usec = tsdPtr->firstTimerHandlerPtr->time.usec -
    blockTime.usec;

     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2001-12-27
    • assigned_to: nobody --> kennykb
     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2001-12-27

    Logged In: YES
    user_id=72656

    I'm not sure that I the patch is really the intent of the
    after command. As noticed, the problem is that Tcl does
    the absolute time calculations, and setting the time back
    means the actual wait is <delta>+1000, instead of 1000
    absolute. Of course, after is asking for relative times.
    Another complication is that after only takes relative
    times, and some people create cron-like agents by
    calculating based on the current time, which would make
    that code incorrect.

    I think this would require a TIP because it is a subtle,
    but significant change.

     
  • Kevin B KENNY

    Kevin B KENNY - 2004-03-05
    • status: open --> closed-rejected
     
  • Kevin B KENNY

    Kevin B KENNY - 2004-03-05

    Logged In: YES
    user_id=99768

    Lacking an absolute reference other than the system
    clock, Tcl assumes that the intent of an [after 60000]
    issued at 10:59 is to wake up at 11:00. If the system
    clock "jumps" or exhibits non-monotonic behavior,
    that assumption is wrong, but there doesn't seem
    to be a good alternative. I know for a fact that [after]
    is widely used for cron-like scheduling, and a change
    this subtle definitely would require a TIP.

    I consider the request ill-advised at present.

    (Really, any Unix-like system that has Internet connectivity
    should be running an NTP daemon, after which there is
    no need ever to set the system clock.)

    I encourage the original requester to post to c.l.t or email
    me to discuss the requirements further, in particular, to
    address what he would consider an appropriate source
    of absolute time to be, in the absence of a trustworthy
    system clock.

     
  • Simon White

    Simon White - 2004-03-17

    Logged In: YES
    user_id=59929

    We use tcl for the graphical interface of an embedded
    instrument. To the user it is the only application running
    and the instrument is standalone (i.e. no network
    connection). The application is responsible for everything,
    it configures all hardware parameters (including system
    clock), lays out embedded windows, has a keyboard manager
    for keyboard navigation (there is no mouse and only a
    simplified keyboard).

    The instrument can take measurements but the visual
    displaying of the results need not be in realtime. Some
    results are performed through slow periodic updates queried
    from tcl is similar loops as shown below.

    We also have a scollable knob on the front panel which
    results in the equivalent of cursor key presses at very high
    speed. We use after to determine when the events have
    slowed down to a sufficient rate that we wont overload the
    cpu when doing work as a result of those events.

    There are also various other cases along these lines. In
    all cases it does not matter if the odd event executes too
    soon from after, as we can if necessary compensate in afters
    callback. However what we cannot deal with is when the user
    adjusts the time such the all those events based of after
    appear to hang.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks