Absolute timeouts and clock adjustments

[Ian Lepore]

On Fri, 2017-02-24 at 15:26 -0600, Eric van Gyzen wrote:
> > 
> > Using CLOCK_MONOTONIC doesn't avoid the issue, it just explicitly
> > asks
> > for the current behavior.  If the behavior you need is to wake up
> > when
> > CLOCK_REALTIME exceeds some value, you're still screwed.
> > 
> > It would be easy enough to fix the current behavior by adding
> > something
> > like "if (timo > hz) timo = hz;" to the existing loop so that
> > CLOCK_REALTIME gets re-checked once a second.
> That would work, but I don't really like introducing spurious wakeups
> just to 
> handle a very rare event.
> 
> How about this approach?
> 
> 	https://reviews.freebsd.org/D9791
> 
> It's also not ideal, and it's obviously much larger than your
> suggestion, but 
> it's very cheap in the common paths.

I would rather add low-frequency wakeups to handle a rare event than
all that extra code complexity.  Anyone who requires real sleep
accuracy won't be relying on a single call to nail the return time
anyway.  The point of a 1hz wakeup is that it's cheap and easy to
implement and good enough to keep code with casual timing requirements
from locking up forever after a big clock step (which tends to happen
on embedded systems without battery backed clocks).

For code that really cares about accuracy (like basically everything we
do at $work), the userland code will do its own looping, with a series
of long sleeps (typically at 1hz) followed by a series of decreasing-
length microsleeps to get the time right.  That's immune to ntpd/ptpd
steering the clock hard, leap seconds, and other things that perturb
accurate sleeps.

But all in all, I don't have strong feelings about it either way.

-- Ian