Re: after ids
- From: Fredderic <my-name-here@xxxxxxxxxx>
- Date: Sun, 6 Jul 2008 16:25:55 +1000
On Sat, 05 Jul 2008 12:56:23 -0400,
Kevin Kenny <kennykb@xxxxxxx> wrote:
All this, simply because I thought that if someone WAS to add an [at]
command to counter-point [after], then I hope to Ghod they don't call it
[at]. ;)
Relative time is not something that Tcl currently recognises,
but perhaps should. It is strictly monotonic and uniform;
it can be thought of as the independent variable of Newton's
Laws of Motion. It is not - indeed, cannot be - tied to any
concept of absolute time outside the computer, since all the
"acts" above can cause dislocations. Nevertheless, it appears
to be what people want in scheduling short-period tasks.
Moreover, the anomalies in time handling on Windows (where
near the Spring and Autumn transitions of Daylight Saving Time,
the "UTC" returned by the system can be an hour off!) appear
to be with us to stay. I've seen bugs in that area in every
Windows release from 3.1 to Vista.
That is how I thought the [after] time worked, for a very long time.
(Mostly courtesy of the documentation.) For that reason I used to write
code that uses [after] to skip a portion of the overall time,
periodically re-calculating the event time in case the clock has
changed in between.
Usually, when I want something to happen after an interval, then that's
exactly what I want. An animation, a network timeout, whatever, if I
can help it at all, I don't want it being sensitive to variations in the
system clock ticking.
Likewise, when I want something to happen [at] a specific time, it's
because the user doesn't want to have to bother with watching a real
wall-clock, or because it needs to mesh in with other events that are
happening in the rest of the system, such as tasks being started by
cron and its ilk. So I *DO* want it to keep in sync as much as
possible with what the rest of my computer believes the time to be. Tcl
having its own private idea of what time is really doesn't help there.
These really are two different use cases, and really don't fit the one
hammer. Although I agree that "normally" they're both satisfied by the
same mechanism, whatever that happens to be. But.....
As for NTP, once or twice a year I go without an internet connection at
all for a week or two, for whatever reason, so I check my clock against
my mobile phone once a day and change it if I happen to notice a
difference of more than a second (as it turns out my system clock
without NTP drifts about a second every three days or so). Also even
with NTP, I don't raise my network interfaces automatically at boot,
and by the time I do, the system's already been up at least 10 minutes,
sometimes as much as a couple hours, which doesn't help the couple Tcl
daemons that are already running at that point.
To further complicate the issue, I do dual-boot, about once every two or
three weeks - the default Wine just doesn't want to play Diablo II or
Civilisation III GE (according to WineHQ, Diablo SHOULD work, but
CivIII gold edition, doesn't). Because I used to go several months
between boots (my system's getting a little old these days), and I'd
only use Windoze once every couple of those, Linux is set to GMT time,
not Windoze compatibility time (I probably should change that, but it
feels too much like a cruel de-evolution of the system). That means
during DST, every time I return to Linux my clock is out by an hour,
and NTP has to bring it back when it starts. The default method, of
which, is to not jump the clock unless it's wrong by at least three
hours, and so it skews the clock back into sync with the rest of the
world over the next couple hours. If I think about it, I'll eye-ball
it roughly into sync (and give the system a couple seconds to settle
back down again), before I bring up the network interface (actually
by kicking the runlevel from 3 up to 4 or 5). But usually it's not a
real big deal and letting NTP skew it for me is a lot nicer on the
various daemons and other programs running (I just have to be careful
with my TV guide firing off alarms at the wrong time ;) ). Also
sometimes if I'm going out, I'll tell the boot-loader to bring it up in
runlevel 4 for me, in which case the network interfaces WILL come up,
but it'll still take a couple hours for the clock to actually match the
one on the wall.
While this stuff is fixable, I could change NTP to jump the time if
it's more than half an hour out, or use ntpdate to jump it before
starting NTP, it is none the less a simple case where saying "have a
working NTP" just really isn't good enough. There are times when NTP
isn't available, and there's not a lot you can do about it...
Personally, if both methods aren't going to be provided, then provide as
close to relative time as possible. The other, wall-clock time, can be
synthesised if needs be, although not nearly as efficiently as the
core could do it.
Fredderic
.
- References:
- Re: after ids
- From: Fredderic
- Re: after ids
- From: Alexandre Ferrieux
- Re: after ids
- From: Donald Arseneau
- Re: after ids
- From: Donal K. Fellows
- Re: after ids
- From: Kevin Kenny
- Re: after ids
- Prev by Date: Re: TCL_STDERR channel not working
- Next by Date: Re: after ids
- Previous by thread: Re: after ids
- Next by thread: Re: after ids
- Index(es):
Relevant Pages
|
