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

[Ingo Molnar]

On Sat, 20 Jul 2002, Linus Torvalds wrote:

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

on the other hand, the application itself cannot even know what exact
absolute time it is, in any unambiguous form - what if right after the
gettimeofday() it got scheduled away and swapped out for many seconds?

so the notion of 'sleep until absolute time X' just brings the 'time
uncertainity' down one more level, it doesnt eliminate it.

the rounding issue is valid when an unlimited number of restarts are
allowed - N x relative timeouts are numerically inaccurate. But there is
no fundamental difference (only performance difference): correct timeouts
can be achieved even if the kernel interface only supports relative
timeouts: the application has to save the absolute target time and has to
recalculate the relative timeout based on the target date and current
date. (which involves multiple calls to gettimeofday(), so it's additional
overhead.)

	Ingo