how does timer: deal with real-time clock changes?

[Ulf Wiger]

The following code in timer.erl seems to define this behaviour:

timer_timeout([{Time, BRef, {repeat, Interv, To}, MFA} | Ts],
              SysTime) ->
    do_apply(MFA),
    Ts0 = insert_sort({Time + Interv, BRef,   %% <<==== here!
                      {repeat, Interv, To}, MFA}, Ts),
    timer_timeout(Ts0, SysTime).

Since it adds Interv (in your case, 1000 ms) to the calculated
trigger time, instead of the actual trigger time, you will end up
with an interval timer that acts like you describe....

...assuming that erlang:now() jumps around when the system clock
is altered!

I thought that erlang:now() had been adjusted on all platforms to
adjust smoothly to changes to the system clock. This is the case
on Solaris, at least. I do not see how the described behaviour
could happen given a well-behaved erlang:now().

The method used to guarantee continuous operation in erlang:now()
is that it samples the system clock and adjusts the clock speed
up to +/- 1% if drift has occurred. Since timer.erl uses
erlang:now(), this should guarantee that the timers fire fairly
regularly. In that case, it's perfectly fine to bump the timeout
interval the way timer.erl does (adding to the calculated time
instead of the actual time.) This will prevent drift due to
scheduling and calculation delays.

/Uffe


On Wed, 10 Dec 2003 matthias@REDACTED wrote:

>Hi,
>
>On R7B-3 on PPC-linux, I just noticed that if I evaluate
>
>  timer:apply_interval(1000, io, fwrite, ["."]).
>
>and then wind back the system time by a large amount (two months), the
>timer seems to stop/freeze/die. Winding the time forward by two months
>causes the timer to execute io:fwrite as fast as it can, i.e. without
>a pause, forever (well, at least as long as I watched).
>
>Doing the same thing on R8A on my desktop seems to cause the timer to
>stop/freeze in both cases.
>
>It seems reasonable for the timer to mess up one interval when the
>time is changed, but it doesn't seem reasonable for it to freeze or go
>wild. Anyone know what's going on? Workaround?
>
>Matthias
>
>