APR_FILES_AS_SOCKETS on Windows

[Juan Rivera <Ju...@citrix.com>]

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?
 
Juan

Re: APR_FILES_AS_SOCKETS on Windows

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

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