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

I agree that one could wish for the functionality of "sleep until a
specified point in real time".  As you indicate, this functionality
is not specified in the current API.  Also, as you indicate and as
Dennis has said, he's only trying to make the implementation conform
to the current API in the face of settimeofday().

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

And the time to sleep till would probably need to be specified in
UTC.

Reason: Recently we had some weirdness with cron on SunOS4 systems.
As you may know, from this year on we in the "middle Europe" time
zone postponed the change from summer back to winter time with one
month.  Of course I hadn't updated our SunOS4 systems with new
zoneinfo files until the last minute, and I didn't reboot our
systems.

End result?  Cron started all subsequent jobs one hour late...

Since the mapping from UTC to local time is done in user space, it
won't be trivial (possible?) to implement the functionality of
"sleep till a specified point in real *local* time" only in the
kernel.  But you all knew that already, right? ;-)

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

Ok, I'll give you that.  But again, I see the addition of
"ITIMER_ABSOLUTE" or whatever we end up calling it if it gets added
as strictly orthogonal to fixing the problems with the current API,
and I think that was all Dennis was proposing to do at the moment.


- H=E5vard