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.