Mercurial > gnulib
changeset 37381:4c67d8dce57a
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.
| author | Eli Zaretskii <eliz@gnu.org> |
|---|---|
| date | Tue, 10 Jun 2014 22:19:13 +0100 |
| parents | a31d5afbb1e4 |
| children | e826982201d2 |
| files | ChangeLog lib/select.c |
| diffstat | 2 files changed, 35 insertions(+), 1 deletions(-) [+] |
line wrap: on
line diff
--- a/ChangeLog Tue Jun 10 21:22:16 2014 +0100 +++ b/ChangeLog Tue Jun 10 22:19:13 2014 +0100 @@ -1,3 +1,11 @@ +2014-06-10 Eli Zaretskii <eliz@gnu.org> + + 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 <eliz@gnu.org> times: fix to return non constant value on MS-Windows
--- a/lib/select.c Tue Jun 10 21:22:16 2014 +0100 +++ b/lib/select.c Tue Jun 10 22:19:13 2014 +0100 @@ -252,6 +252,7 @@ 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 @@ /* 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 @@ 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 @@ } } - 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 @@ SleepEx (1, TRUE); goto restart; } + if (timeout && wait_timeout == 0 && rc == 0) + timeout->tv_sec = timeout->tv_usec = 0; } /* Now fill in the results. */