Re: PATCH: Support Windows in event-loop.c

[Christopher Faylor <me@cgf.cx>]

On Fri, Apr 22, 2005 at 04:20:40PM +0300, Eli Zaretskii wrote:
>> Date: Fri, 22 Apr 2005 08:08:04 -0400
>> From: Christopher Faylor <me@cgf.cx>
>> 
>> Well, again, I have a rather major technical concern about the use of
>> WaitForMultipleObjects in this scenario, so as the Windows maintainer,
>> I'd like to see that addressed.  You can't reliably just use
>> WaitForMultiple on, say, a serial port, a socket, or a pipe, so I don't
>> know how this would ever work.
>
>I'm not sure I understand what you are saying, Chris.  Are you saying
>that there's no known way of emulating the Posix `select' on Windows
>in a way that would work on serial ports and pipes?  (I assume sockets
>are a non-issue, since the Windows implementation of `select' supports
>them.)

I'm saying that you can't just use WaitForMultipleObjects as a
replacement for select.  You have to go to more effort than that,
unfortunately.

AFAIK, the only file-like device that can be used in
WaitForMultipleObjects is the windows console.

>Or are you saying that WaitForMultipleObjects is not the way to write
>such an emulation?  If so, what system calls are better candidates?
>
>FWIW, the Emacs emulation of `select' does work on pipes, so it seems
>that at least in that case there's code to borrow.

Cygwin's emulation does too, but it doesn't use WaitForMultipleObjects.
AFAIK, the only way to do non-blocking reads on normal pipes is to poll
the pipe with the PeekNamedPipe call.  It's ugly and painful.

The Windows API is full of interesting and useful stuff mixed together
with inexplicably annoying and limited stuff.

>If we cannot make a `select' emulation that works for some of these
>devices, we could simply document them as a limitation.  That doesn't
>make the Windows build worse than it is now, does it?

Cygwin has a fully functional select (at least for the read side of
things) so it is possible to come close.

FWIW, you can do non-blocking I/O on serial handles by opening them in
"overlapped" mode but I don't know if there's any way to do that via
the UNIX-lite "fopen/open" MSVCRT interface.

cgf