> 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()?
> 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.
True... I found this:
> 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?
What about using a socketpair instead? We can implement that for
Windows using TCP/IP sockets.
> For reference, here is the code that is in use in clisp to detect whether
> reading from a handle would hang or return immediately. The deal with
> ENABLE_LINE_INPUT is that PeekConsoleInput will say "yes there is something
> is available" as soon as the user has started typing a line, but ReadFile
> will hang until the user presses Return.
Yes, it makes sense to add it to the select/poll emulations. I didn't
know about ENABLE_LINE_INPUT.
> {
> 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.
Unfortunately HP TestDrive will be discontinued tomorrow, and I won't
have access to Windows anymore again. :-(
Paolo
