Hi,
Since the WIN32 imposes pretty nasty limit on FD_SETSIZE to 64, that is way too low for any serious usage, I developed an alternative implementation. Also the code support the APR_POLLSET_THREADSAFE flag.
A simple patch to apr_arch_poll_private.h allows to have multiple implementations compilable.
Any comments?
Regards, Mladen.
Brain dump...
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 between async 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 buffer (ie, 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? Dunno...)
Bill
