Hi,
(summary for the recall)
> things like select(1,[0],[],[],[0,0..999]) always return 0 immediately
About the 0..999 range, it's just that the timeout value is divided (and
rounded down) by 1000.
Now, we have a pile of issues: in gnumach's ipc_mqueue_receive(), if
time_out is zero, the function returns MACH_RCV_TIMED_OUT even if a
message is ready. But anyway, since by design select() on the Hurd is
not necessarily synchronous (since it implies querying a server), the
reply can't be ready so fast.
Actually, on the Hurd, a timeout of 0 probably doesn't make sense (since
we at least need to give back cpu to the server). What I'd propose is
the attached patch (not tested), that rounds up the timeout value, and
in the case of 0, uses 1 (so as to give the server an opportunity to
answer).
Comments?
Samuel
Index: hurd/hurdselect.c
===================================================================
RCS file: /cvs/glibc/libc/hurd/hurdselect.c,v
retrieving revision 1.6
diff -u -p -r1.6 hurdselect.c
--- hurd/hurdselect.c 2 Apr 2002 04:41:45 -0000 1.6
+++ hurd/hurdselect.c 8 Jun 2007 17:27:45 -0000
@@ -50,10 +50,7 @@ _hurd_select (int nfds,
error_t err;
fd_set rfds, wfds, xfds;
int firstfd, lastfd;
- mach_msg_timeout_t to = (timeout != NULL ?
- (timeout->tv_sec * 1000 +
- timeout->tv_nsec / 1000000) :
- 0);
+ mach_msg_timeout_t to;
struct
{
struct hurd_userlink ulink;
@@ -75,6 +72,15 @@ _hurd_select (int nfds,
if (sigmask && __sigprocmask (SIG_SETMASK, sigmask, &oset))
return -1;
+ if (timeout == NULL)
+ to = 0;
+ else
+ {
+ to = timeout->tv_sec * 1000 + (timeout->tv_nsec + 999999) / 1000000;
+ if (!to)
+ to = 1;
+ }
+
if (pollfds)
{
/* Collect interesting descriptors from the user's `pollfd' array.
