Hi Paolo,
In some cases, the select() emulation returns 0 even when no timeout was
specified. I use it in msgfilter for communication with a subprocess.
- Initially I call select() on 2 file descriptors: an fd for parent<-child
and another for child->parent writing. select() reports that writing is
possible, so I write something. Twice.
- Then I want to collect all the output of the subprocess. I call select()
with just 1 fd: for parent<-child communication. select() returns 0, although
no timeout was given!
How about adding an assertion like this?
*** lib/winsock-select.c.orig 2008-09-29 19:16:21.000000000 +0200
--- lib/winsock-select.c 2008-09-29 19:03:58.000000000 +0200
***************
*** 25,30 ****
--- 25,31 ----
#if (defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN__
#include <sys/types.h>
#include <stdbool.h>
+ #include <stdlib.h>
#include <errno.h>
#include <limits.h>
***************
*** 412,417 ****
--- 413,421 ----
}
}
+ if (!timeout && rc == 0)
+ abort ();
+
return rc;
}
The problem in the implementation is that MsgWaitForMultipleObjects returns
a value indicating that handle number 1, i.e. the one associated with my
pipe, is signaled. The PeekNamedPipe call inside win32_poll_handle then is
successful and sets 'avail' to 0. This is a bit of a contradiction.
If, as a response to this situation, I repeat the code starting with
MsgWaitForMultipleObjects, this loop is performed about 300 times on
average, until at some point 'avail' becomes 1 and select() returns
correctly.
But I am afraid to propose this as a fix, because this is busy-looping, and
the purpose of select() is to avoid busy-looping.
Any idea? To reproduce, you find the code in
http://www.haible.de/bruno/gnu/gettext-0.18-pre3.tar.gz
Bruno
