Re: after ids
- From: "Donal K. Fellows" <donal.k.fellows@xxxxxxxxx>
- Date: Sat, 5 Jul 2008 07:32:19 -0700 (PDT)
Donald Arseneau wrote:
This comes up repeatedly and I very strongly disagree.
This comes up repeatedly because nobody seems to want to bite the
bullet and say how to make things work in real code. Your agreement or
otherwise with this state of affairs is irrelevant (unless you write a
patch, of course).
The [after]
command is documented to implement intervals, not wall-clock. The
fact that it has hiccups when the wall clock changes is just a
long-standing bad bug, and is no reason to retain the incorrect
behavior.
OK, how do you work out how long until the next event fires without an
absolute time source? For added bonus points, do so with arbitrary
real-time delays between processing points and without extra threads.
On the other hand, almost every use of
[after] is to implement a short delta-time delay, and these break
badly once or twice a year with the current [after].
Only on Windows, which is surprised by the occurrence of timezone
changes twice a year, and Linux, which tries to emulate the stupidity
of Windows so that dual-booting doesn't break. Sane systems don't
change their clocks when when DST goes into force or when they are
moved between timezones; they just change how they render the clocks.
What I've never figured out is which idiot decided this was a
(mis)feature and not a flat bug.
Can't we follow the principle of least surprise here?
I'd like to hear how you work out when a timer is ready to fire.
Donal.
.
- Follow-Ups:
- Re: after ids
- From: Kevin Kenny
- Re: after ids
- From: Alexandre Ferrieux
- Re: after ids
- References:
- Re: after ids
- From: Fredderic
- Re: after ids
- From: Alexandre Ferrieux
- Re: after ids
- From: Donald Arseneau
- Re: after ids
- Prev by Date: Re: newbie
- Next by Date: Re: after ids
- Previous by thread: Re: after ids
- Next by thread: Re: after ids
- Index(es):
Relevant Pages
|
