Re: [PATCH][4/4] poll()/select() timeout behavior

[Jamie Lokier <jamie@shareable.org>]

Andrew Morton wrote:
> > Unfortunately, fixing the fencepost error places a hard lower limit of
> > 1/HZ on the time slept, and increases the average minimum sleep time
> > threefold, from 1/(2*HZ) jiffy to 3/(2*HZ).
> 
> I'm inclined to live with the current behaviour rather than
> risk breaking existing apps.

select's behaviour is fun when trying to do smooth game animation on
X...  Humans are pretty good at noticing jitter in the animation of a
moving object.  Years ago, I ended up writing an estimator which
deduced the granularity and rounding of select(), so that I could then
_reduce_ the timeout given to select() followed by a busy wait up to
the desired time.  That was needed for SunOS.  Nowadays with 1kHz
jiffies it's not a problem, but not all systems have that.

So, I agree, the change might break current apps.

If the current behaviour is retained, shouldn't select(), poll() and
epoll() at least agree on the same rounding direction?  poll/epoll
should be suitable as replacements for select, but I don't think they
are timing-wise.

(Btw, Bill, did you take a look at epoll too?)

-- Jamie