apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Stoddard <b...@wstoddard.com>
Subject Re: [WIN32] alternative apr_pollset implementation proposal
Date Tue, 19 Apr 2005 13:31:41 GMT
Mladen Turk wrote:
> 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...)


View raw message