Linux doesn't do it's best efforts to ensure that select returns as
specified in the man page. Even on an unloaded system, it waits between
10 and 20 ms longer than the specified timeout (depending on when the
next timer interrupt is due). This is my complaint (and the complaints
of the original poster).
It's perfectly ok to have higher priority tasks preempt lower priority
tasks, which causes unexpected delays to the lower priority tasks - this
has nothing to do with select(2) semantics. But it is *not* ok to
declare darkness as standard and don't try to do the best. Especially
when it is only two lines of code to change.
BTW POSIX: the single unix spec v2
(http://www.unix-systems.org/single_unix_specification_v2/xsh/select.html)
sais
"If the timeout argument is not a null pointer, it points to an object
of type struct timeval that specifies a maximum interval to wait for the
selection to
^^^^^^^^^^^^^^^^
complete. [...]"
Contradictionary, it later sais
"Implementations may also place limitations on the granularity of
timeout intervals. If the requested timeout interval requires a finer
granularity than the implementation supports, the actual timeout
interval will be rounded up to the
^^^^^^^^^^
next supported value."
Rounding down would support the "maximum interval" above, but after all,
if the app knows about the granulatrity, it can do the rounding itself,
and isn't affected by this bogus rounding of the OS. Personally, I would
prefer something that works with either the microsecond patch or the
standard distribution, without checking the actual granularity by the
app before.
This is what Linux should do: try its best to ensure that select()
doesn't unnecessarily wait longer than specified. If higher priority
tasks preempt - well, that's live. But if there are no higher priority
tasks, return as late as possible, but before the timeout expires.
The Linux code now is just one off. Is this so difficult to accept that
it is one off even after years of use? Can't it be fixed without harsh
words?
-- Bernd Paysan
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/