Re: after ids

Alexandre Ferrieux wrote:
[why ignore this for over a year?]

Uhm, because I've been working on other things? I've been *wanting*
to do a better data structure for [after] for almost ten years now,
and more important things keep coming up. Of course, if someone
*else* were to implement it, shepherding it into the Core would have
a higher priority. :)

(2) I disagree with the comment. Quoting you:

> The times function in Unix is not an appropriate time base.
> It reports the user and system time (CPU time, in other words)
> of the currently executing process and its children...

What you say accurately describes what times() returns in its argument
structure. But it also has a return value, which is of type clock_t,
and, quoting the manpage:

>> times() returns the number of clock ticks that have elapsed
>> since an arbitrary point in the past.

So again, why is not an appropriate time base ?

At some point, I understood that the return value of times() was
actually calculated by subtracting gettimeofday() from the
bootload time, so it wasn't guaranteed to be monotonic. If that
is the case, it's no better than [after] is today, and in fact
is worse because it's reliable as neither an absolute nor a
relative standard. If in fact it is monotonic, and has a
stable frequency reference backing it up, then it would be
an ideal choice. (These implementation details are nasty!)

Yes but not everybody has this. I routinely get to handle machines
jailed in strange subnetworks with armies of firewall around, and NTP
not an option. Nor would it deserve any effort: on these machines,
accuracy of the 'date' command is not required.

Nowadays, that seems a rather strange environment. In particular,
it presumes that shared filesystems (or even rsync) are not
required to be coherent, since strange things start to happen
if the system time on a machine that is writing files drifts
too far from the system time on the machine where they live.
Blocking NTP at firewalls, and providing no alternative,
seems to be the act of a sysadmin that is actively hostile to
the users. Nevertheless, if that's what you have to deal with,
and it isn't *too* hard to support it, I suppose we can work
up something.

Even today, the [after] command doesn't depend on time zone changes,
Yeah, this red herring has been covered to death on c.l.t :-)
We both know TZ and DST are a separate layer from the true time base
ticking [after], let's dismiss that.

The reason that it's been discussed to death is largely that it
was *not* true once upon a time. Windows prior to Windows 2000
kept the hardware clock set to local time, and there was a glitch
at "fall back" that could be avoided only by intercepting the
WM_SETTINGSCHANGED message, reading the clocks, and rescheduling
everything. (Moreover, there was a race condition where the
WM_SETTINGSCHANGED could awaken a process before the settings
change had actually propagated all the way!) Tcl tripped over
*that*, too. Fortunately, Win9x and WinNT 3.51 are things of the past.

I would be very surprised to see a single example of a beneficial, or
even depended-upon, effect of a gettimeofday()-shift on [after].
I have one important one: NBC.
[...] So unlike your assertion that the
hardware clock is "rock solid" while system time is capricious,
in the NBC system, system time is traced to a primary reference

OK, I understand the specific need, but:

(1) this is closer in my view to an [at] command, rather than an

Indeed, and I'm all in favour of implementing [at] - just haven't
had the time to do it myself (and it *does* need a TIP).

(2) even with a ticks-based, drifting time reference in [after], it
would be easily achievable with a two-resolution scheme: a periodic
task running every (say) minute, checking [clock], and posting short-
range [after]s.

Assuming, as said earlier, that an appropriate timebase is available
in userland. If I'm wrong about times(), then that problem is solved.

(3) Conversely, even in the current implementation, with a tight NTP
hand on the system clock, if there is one single long [after] with no
intervening events, Tcl will compute one single select() timeout
value, and the syscall will sleep until its end, regardless of any
intervening NTP corrections; so it will suffer from the drift. Of
course, this won't happen if the select() is frequently interrupted by
other events (including shorter-term afters), since in this case
gettimeofday() is called at each time to recompute the next target).
Is it your case ?

Since the UI has a clock displaying seconds, the select() in my
process never sleeps for more than a second. (Also, the workload
is such that I'd expect it never to sleep for more than a few
seconds in any case.)

In any case, I think we're in some form of "violent agreement" -
we both agree that

- separating [after] from [at] would be a good idea, even
irrespective of the chosen timebase.
- tying [after] to a stable relative timebase - assuming
that we can find one - is another good idea.
- irrespective of those two points, a data structure capable
of handling a large schedule of timers without performance
anomalies would be another good thing, and this last bit
can be done without a TIP.

We disagree on priorities (who doesn't?), largely because of
different experience. I work in a lot of strange places, but
it's been years since I last set a system clock with wristwatch
and eyeball. You obviously labor under different constraints.