Re: [PATCH v2] implement full-blown select(2) for winsock

[Bruno Haible]

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