Re: {sys_,/dev/}epoll waiting timeout

[Jamie Lokier <jamie@shareable.org>]

Mark Mielke wrote:
> Sorry... not 1 in 1001... almost 100% chance of returning of one
> jiffie too many.

It's curious that select() is different from poll() - almost is if
completely different people wrote the code :)

We have to wonder whether it was a design decision.
Perhaps the unix specifications require it (see below).

> In practice, even on a relatively idle system, the process will not
> be able to wake up as frequently as it might be able to expect.

You're right - it's unfortunate that using poll() lets you sleep and
wake up no faster than every _two_ ticks.  That's actually caused by
poll()'s treating zero differently though, not by +1 as such.

There's a strange contradiction between rounding up the waiting time
to the next number of jiffies, and then rounding it down (in a
time-dependent way) by waiting until the next N'th timer interrupt.

If, as someone said, the appropriate unix specification says that
"wait for 10ms" means to wait for _at minimum_ 10ms, then you do need
the +1.

(Davide), IMHO epoll should decide whether it means "at minimum" (in
which case the +1 is a requirement), or it means "at maximum" (in
which case rounding up is wrong).

The current method of rounding up and then effectively down means that
you get an unpredictable mixture of both.

-- Jamie

ps. I would always prefer an absolute wakeup time anyway - it avoids a
race condition too.  What a shame none of the system calls work that way.

pps. To summarise, all the time APIs are a complete mess in unix, and
there's nothing you can do in user space to make up for the b0rken
system call interface.  Except not duplicate past errors in new interfaces :)