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 Thu, 21 Apr 2005 15:57:48 GMT
James Mansion wrote:
>>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.
> 
> 
> I'm not sure the technique you describe will work.
> 
> Consider an alternative approach:
> 
> 1) from a poll perspective, consider a socket that does not have an
> overlapped operation in progress as ready for writing.  Write to a buffer
> that's owned by the poller and then run the overlapped or IOCP from that.
> 
> 2) for reading, always have an OVERLAPPED operation running against a
> poll-owned buffer - unless the read side has been shutdown or we're not yet
> connected.  If this buffer is not empty, poll considers it readable.
> 
> Extra buffer copies are needed but it does the job.  We're just using a
> buffer/queue to translate between push and pull structures, after all.
> 
> James

I like this approach and we can probably work out how to do reads w/o introducing an additional
buffer copy. 
The buffers would get morphed into immortal buffer types and ownership of the buffer would
be passed to the 
polling (or worker?) thread.

Bill




Mime
View raw message