It may be possible to use IOCompletionPorts on Windows to implement apr_pollset_*. IOCPs
aare very scalable
but moving to IOCPs will require a complete rewrite of the apr_socket implementation on Windows.
And there is
the small matter of a simple technical issue that needs to be investigated...
IOCPs support true async network i/o. BSD KQ, Solaris /dev/poll, epoll et. al. are not async,
they are event
driven i/o models. When you issue an async read on Windows, the kernel will start filling
your i/o buffer as
soon as data is available. With event driven i/o, the kernel tells you when you can do a read()
and expect to
receive data. See the difference? Your buffer management strategy will be completely different
i/o and event driven i/o and I am not sure how APR (or applications that use APR) can be made
to support both
cleanly. So back to the small technial issue that needs to be investigated...
I believe (but have not verified) that it is possible to use IOCPs to emulate event-driven
network i/o. When
you make read or write calls for which you want to emulate event driven i/o, pass in a 0 length
you can manage your i/o buffers using event driven semantics). So if you issue a read passing
in a 0 length
buffer, your IOCP will get notified when there is data to read. I think :-)
Assuming the above technique works reliably, we still need to figure out how to optimize the
i/o. In general,
if there is data to read or write, synchronous calls are more efficient (if there is data
to read, then just
read it rather than telling the kernel to tell you via a notification method that there is
data to read. How
do you do that on Windows if you want to emulate event driven i/o?