At 09:57 AM 6/3/2003, Juan wrote: >It APR says: "Win32 cannot poll [just yet] on files/pipes". > >What exactly needs to be there to support polling on files/pipes along with >sockets? Is it a limitation with win32 select?
Correct. Neither the faux-select() nor even my reimplementation of poll.c for Win32 that leans on the WSAEventSelect() API will poll on a file. Win32 is very good at async notification of the *completion* of various operations on sockets and files, e.g. the packet is read by the app, the file has been flushed by the os, etc. But it is not terribly good at async notification of *ready* events, except in the case of sockets. There are some peek-ahead APIs available for Win32, and I haven't yet explored how those could be plugged in (perhaps with a periodic 500ms sleep between peeks). The documentation can be read two ways when it comes to a signalled pipe handle. One reading implies there is data to be read. But that isn't what I've observed, and it isn't what the documentation implies. I had to revert the 'async pipe' flags a few releases ago, because those async pipes (that may be timed out) weren't suitable for passing on to the child process. That is an issue that needs reinvestigation, how to 'toggle' blocking v.s. completion/timeout pipes on Win32. It almost looks like our pipe needs would be better served with loopback sockets; except that the loopback drivers are historically buggy (see the MSKB for examples.) Bill
