Subject: Re: settimeofday() versus interval tim{ers,ing}
To: None <tech-kern@NetBSD.ORG>
From: der Mouse <mouse@Holo.Rodents.Montreal.QC.CA>
List: tech-kern
Date: 10/04/1996 06:27:12
>> Given the manpage for setitimer, it sounds to me as though it is
>> specced to provide the "sleep for a specific interval" service, in
>> which case that's what it should do, sleep for some number of clock
>> ticks (this gets more complicated if you want to get the interval as
>> right as possible even in the presence of adjtime calls).

> I'm told only the "truly anal" would care about the difference
> bewteen raw ticks and adjtime/NTP-adjusted ticks; welcome to the
> club.

How much does adjtime() slew the clock by, default?  .1%?  Then if you
sleep for a thousand ticks - ten seconds on most machines - you can be
as much as a whole tick out thanks to adjtime.  I know _I_'d certainly
be annoyed if I requested a timer tick once a second and then,
according to gettimeofday(), actually got it every 1.001 second,
thereby slowly drifting with respect to second boundaries.

>> Perhaps it would be enough to provide a way for a program to arrange
>> to be awoken whenever settimeofday() is called.  Perhaps select()ing
>> for read on /kern/time? :)

> I had thought of inventing a new kind of "itimer", ITIMER_ABSOLUTE
> or something, [...]

That would help too...but there are also programs (cron, for example)
that want to take positive action when the time of day steps, not just
be awakened on a time-of-day basis - cron, for example, needs this so
that if the timewarp is backwards, it runs jobs twice correctly.  (If I
set the time back by a day, I don't want cron to lock up solid for a
day, waiting until gettimeofday() catches up with when cron thought the
next cron job was scheduled for, and therefore slept until.)  Of
course, cron couldn't _just_ use ITIMER_ABSOLUTE, since it also has to
watch for new crontabs being installed.

This leads into another reason why ITIMER_ABSOLUTE isn't a complete
solution: it doesn't address the desire to pass an absolute time as the
fifth argument to select().  The only real solution I see to _that_ is
to add a third field to a struct timeval, specifying whether it's
absolute or relative.  But of course doing that breaks both source (and
binary, unless you renumber a handful of syscalls) compatability.
Sigh.  As well as compatability with the rest of the known universe.
Double sigh.  I guess the only even semi-workable thing to do is to
provide an abstime_select() call.  Yech.

					der Mouse

		     01 EE 31 F6 BB 0C 34 36  00 F3 7C 5A C1 A0 67 1D