The basic problem here seems to me to be that different programs want
to do different things.  In particular, some processes want to sleep
until a specific time; others want to sleep for a specific interval.
Unfortunately, the current itimer interface cannot satisfy both of them
in the presence of clock steps, no matter _what_ you do with boottime
and mono_time and whatnot inside the kernel.  It gets even more
complicated in the presence of processes that want to do things like
"sleep until 16:55, then awaken every second thereafter", which are
hybrids of the two paradigms.

Or was someone proposing changes to the API?  If so, I'm afraid I
missed it; the only thing I saw was talking about changing the kernel
internals.

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).  Programs
wanting to sleep until a specific time are, AFAICT, presently out of
luck; until some absolute-time analog of itimers get defined, about the
best they can do is sleep for some reasonable smallish time, polling
the time of day when they wake up.

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? :)

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     01 EE 31 F6 BB 0C 34 36  00 F3 7C 5A C1 A0 67 1D