Hello Paolo,
> > How about adding an assertion like this?
> >
> > + if (!timeout && rc == 0)
> > + abort ();
>
> But wouldn't this trigger in your case, thus aborting select() and poll()?
Yes it would currently abort in select(). But it would force us to fix the
problem in a way that does not violate the assumptions programs make about
select(). POSIX says:
"If none of the selected descriptors are ready for the requested operation,
the pselect() or select() function shall block until at least one of the
requested operations becomes ready, until the timeout occurs, or until
interrupted by a signal."
I have an abort() when my code calls select without timeout and select()
returns 0. It's better if this abort() is in the implementation of select(),
so that we can see the problem earlier.
> > The code above fails (or rather, WaitForSingleObject fails) when the
> > above is run by two threads, not two processes. I originally tested it
> > in two completely separate executables. Now that I want to run this
> > within two threads in the same Windows DLL, WaitForSingleObject doesn't
> > actually do any waiting.
>
> Is it your case?
No, my case is a single-threaded program that reads and writes to a child
process through pipes.
> What about using a socketpair instead? We can implement that for
> Windows using TCP/IP sockets.
No, please. I don`t need sockets. For communication with a subprocess, all
I need is a pipe. Sockets would be an overkill for that.
> > {
> > DWORD nbytes;
> > if (PeekNamedPipe(fd,NULL,0,NULL,&nbytes,NULL)) { /* input pipe */
> > if (nbytes > 0)
> > return 3;
> > else
> > return 0;
> > } else if (GetLastError()==ERROR_BROKEN_PIPE) { /* EOF reached */
> > return 2;
>
> ... and this could also be used to emulate POLLHUP on pipes, which is
> pretty cool because even Cygwin fails on that.
Yes. It took some amount of testing to find out how to detect these two
situations. The Microsoft docs are far from complete descriptions.
Bruno
