Re: [PATCH] 'select' failure or signal should not update timeout

[Eric W. Biederman]

[e-mail] (Linus Torvalds) writes:

> In article <[e-mail]>,
> Alan Cox  <[e-mail]> wrote:
> >> <http://www.opengroup.org/onlinepubs/007904975/functions/select.html>
> >> says that 'select' may modify its timeout argument only "upon
> >> successful completion".  However, the Linux kernel sometimes modifies
> >> the timeout argument even when 'select' fails or is interrupted.
> >
> >This is extremely useful behaviour. POSIX is broken here. Fix it in the
> >C library or somewhere it doesn't harm the clueful
> 
> Personally, I've gotten to the point where I think that the select()
> time is broken. 
> 
> The thing is, nobody should really ever use timeouts, because the notion
> of "I want to sleep X seconds" is simply not _useful_ if the process
> also just got delayed by a page-out event as it said so.  What does "X
> seconds" mean at that point? It's ambiguous - and the kernel will (quite
> naturally) just always assume that it is "X seconds from when the kernel
> got notified". 
> 
> A _useful_ interface would be to say "I want to sleep to at most time X"
> or "to at least time X".  Those are unambiguous things to say, and are
> not open to interpretation.

Sleeping until at most time X is only useful if the kernel can actually
make a guarantee like that.  If you are doing hard real time fine, otherwise
that doesn't work to well.
 
> The "I want to sleep until at least time X" (or "at most time X") also
> has the added advantage that it is inherently re-startable - restarting
> the sleep has _no_ rounding issues, and again no ambiguity.
> 
> Note that select() is definitely not the only offender here.  Other
> system calls like "nanosleep()" have the exact same problem - what do
> you do if you get interrupted by a signal and need to restart? 
> 
> The Linux behaviour of modifying the timeout is a half-assed try for
> restartability, but the problem is that (a) nobody else does that or
> expects it to happen, despite the man-pages originally claiming that
> they were supposed to and (b) it inherently has rounding problems and
> other ambiguities - making it even less useful. 
> 
> Oh, well.
> 
> I suspect almost nobody actually uses the Linux timeout feature because
> of the nonportability issues, making the whole mess even less tasty.

Actually I have had occasion in dosemu to not use the timeout features
because it did not do a good job of attempting to sleep for X seconds.
There can be a lot of time from when the kernel updates the timeout
value, and when the system call is restarted.

The desired semantics in this case were I want to sleep until time X,
and I want to wake up as soon afterwards as is reasonable.  Calling
gettimeofday before restarting the system call resulted in a much
better approximation of the desired result.

Eric