In message <199610030157.VAA04194@Collatz.McRCIM.McGill.EDU>,
der Mouse writes:


>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.

It's worse than that. The current itimer interface doesn't really
get either class of usage correct. No-one gets quite what they want.


>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.

Yes, they were.  That was me.  Twice.  Others  missed it too,
at least judging by the non-sequitur responses it got.

I'm also the one who keeps saying that that there *are*
two  classes of use, as you also point out; and


>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).

Perhaps. itiemrs and settiomefday() are roughly coe\"val. Both
appeared in 4.2BSD.  Ajdtime() appeared in 4.3BSD.  I'm told
only the "truly anal" would care about  the difference bewteen
raw ticks and adjtime/NTP-adjusted ticks; welcome to the club.
(But see  also the "fat tick" problems; I forget the NetBSD PR number.)


>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,  time-of-day is  greater to, or equals, the
time-of-day in the itimer, interpreted as an *absolute* time,
not a time delta (interval).   That removes any race between
finding the current time (via gettimeofday()), computing a delta
and setting an itimer, and a concurrent call to settimeofday().

I don't see how the  suggestion of using itimers to poll
until the desired real time addresses this; one can always lose
by the poll interval.

The kernel can do the conversion from absolute to relative
time "safely". It then just needs to adjust the delta of
absolute itimers when the time-of-day  jumps.

The itimer-adjustment  code in FreeBSD may already do just
what's wanted here, but on a different set of itimers.