Re: Bug: epoll_wait timeout is shorter than requested

[Jamie Lokier <jamie@shareable.org>]

Jamie Lokier wrote:
> > Well, if the kernel measured the delay more accurately than to a clock
> > tick, it could notice that a requested 1ms would be satisifed by, say,
> > 8ms which remained from the current tick.
> 
> I agree 100%!  That's a good solution.
> 
> If select/poll/epoll were implemented by the kernel reading the
> current time accurately before deciding how many ticks to wait for,
> they could satisfy SUSv3's constraint, _and_ allow the useful
> behaviour of application events at the tick rate, _and_ reduce the
> number of system calls in some programs which call select().
> 
> If you want to change the code in fs/select.c and fs/eventpoll.c to do
> this, please do so; I'll be happy to support the case for it.

That said, _any_ change to select/poll is sure to break some programs,
which depend on the current quirks.

By the way, the most logically useful interface would take an
*absolute* end time, in any of the forms that the POSIX timer code allows.

This is because nearly every application which calls select/poll/epoll
with a timeout first calls gettimeofday() and then computes the
difference between an absolute time and the current clock time to pass
as the timeout argument - introducing a race condition in the process.

Giving an absolute time would eliminate the race condition _and_ all
calls to the microsecond timer, which is often quite slow.

However, that would require adding yet another non-standard interface.
Perhaps a case can be made for epoll_wait_abstime or something like
that, seeing as epoll is quite non-standard anyway.

-- Jamie