[PATCH.HURD] Limit the minimum timeout delay to 1us for hurdselect.c to avoid problems

[Svante Signell]

Hello,

I'm currently working with an update of hurdselect.c in eglibc, and
found a problem with non-blocking delays of value zero. This problem has
been seen before for vi for select and a workaround hack is currently in
the Debian version of eglibc-2.13. I have also seen this problem with my
new implementation of hurdselect, both for poll() and select(). The
updated code seems to be a little faster for the zero timeout case on my
kvm box, so the problems are revealed with the new version. This problem
is an old one, see Debian bug http://bugs.debian.org/79358. 

Attached is test code to check this problem with both poll() and
select() options. 
>From the Linux man-page for poll:
"Specifying a timeout of zero causes poll() to return immediately, even
if no file descriptors are ready." '

POSIX.1-2001 specifies ofr poll():
"If the value of timeout is 0, poll() shall return immediately,..."
not saying anything about file descriptors being ready or not.
and for select():
"To effect a poll, the timeout parameter should not be a null pointer,
and should point to a zero-valued timespec structure."

The attached patch is about the same as in Massage 53 of that bug,
limiting the smallest timeout to be 1us. The difference is that it does
not set the timeout to zero if it is given as NULL. This value seems to
work OK both for poll and select cases. Of course this value has been
found by trial and error, but when computers get faster and faster this
value would be an even better bet (unless other problems show up). The
patch is a diff of the patched Debian file.

test_timeout.c
Description: Text Data

hurdselect_timeout.patch
Description: Text Data