>From aaaf546f290eb87b0113ed8ddbacc1cf2f1e2e57 Mon Sep 17 00:00:00 2001 From: Eli Zaretskii Date: Tue, 10 Jun 2014 22:19:13 +0100 Subject: [PATCH] select: fix waiting on anonymous pipes on MS-Windows The existing select() implementation for MS-Windows returned immediately with a zero value when it is called to wait for input from an anonymous pipe (e.g., a pipe created by a call to 'pipe' or 'pipe2'), as discussed at: http://lists.gnu.org/archive/html/bug-gnulib/2011-06/msg00008.html This was noticed while running Guile's test suite on MS-Windows. Guile uses 'select', among other places, in its implementation of 'sleep' and 'usleep' primitives. It calls 'select' with a file descriptor of a signal delivery pipe, which is written to (by another thread) when Guile is interrupted by a signal. But due to the above-mentioned problem, these two functions never sleep, and instead return immediately. * lib/select.c (rpl_select): Fall back to polling when select() indicates there is nothing to check, while due to the timeout not expiring, activity is indicated on one of the handles. Also clear the TIMEOUT argument if the timer does expire. --- ChangeLog | 8 ++++++++ lib/select.c | 28 +++++++++++++++++++++++++++- 2 files changed, 35 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index 105befe..d2a42fe 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,13 @@ 2014-06-10 Eli Zaretskii + select: fix waiting on anonymous pipes on MS-Windows + * lib/select.c (rpl_select): Fall back to polling when select() + indicates there is nothing to check, while due to the timeout not + expiring, activity is indicated on one of the handles. + Also clear the TIMEOUT argument if the timer does expire. + +2014-06-10 Eli Zaretskii + times: fix to return non constant value on MS-Windows * lib/times.c (times): Don't use the process creation time, rather clock() which on windows returns the number of diff --git a/lib/select.c b/lib/select.c index 1ca0d35..a12f372 100644 --- a/lib/select.c +++ b/lib/select.c @@ -252,6 +252,7 @@ rpl_select (int nfds, fd_set *rfds, fd_set *wfds, fd_set *xfds, DWORD ret, wait_timeout, nhandles, nsock, nbuffer; MSG msg; int i, fd, rc; + clock_t tend; if (nfds > FD_SETSIZE) nfds = FD_SETSIZE; @@ -388,6 +389,10 @@ rpl_select (int nfds, fd_set *rfds, fd_set *wfds, fd_set *xfds, /* Place a sentinel at the end of the array. */ handle_array[nhandles] = NULL; + /* When will the waiting period expire? */ + if (wait_timeout != INFINITE) + tend = clock () + wait_timeout; + restart: if (wait_timeout == 0 || nsock == 0) rc = 0; @@ -408,6 +413,16 @@ restart: wait_timeout = 0; } + /* How much is left to wait? */ + if (wait_timeout != INFINITE) + { + clock_t tnow = clock (); + if (tend >= tnow) + wait_timeout = tend - tnow; + else + wait_timeout = 0; + } + for (;;) { ret = MsgWaitForMultipleObjects (nhandles, handle_array, FALSE, @@ -453,7 +468,16 @@ restart: } } - if (rc == 0 && wait_timeout == INFINITE) + if (rc == 0 + && (wait_timeout == INFINITE + /* If NHANDLES > 1, but no bits are set, it means we've + been told incorrectly that some handle was signaled. + This happens with anonymous pipes, which always cause + MsgWaitForMultipleObjects to exit immediately, but no + data is found ready to be read by windows_poll_handle. + To avoid a total failure (whereby we return zero and + don't wait at all), let's poll in a more busy loop. */ + || (wait_timeout != 0 && nhandles > 1))) { /* Sleep 1 millisecond to avoid busy wait and retry with the original fd_sets. */ @@ -463,6 +487,8 @@ restart: SleepEx (1, TRUE); goto restart; } + if (timeout && wait_timeout == 0 && rc == 0) + timeout->tv_sec = timeout->tv_usec = 0; } /* Now fill in the results. */ -- 1.7.7.6