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
(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.
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 :)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jan 23 2003 - 22:00:32 EST