Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <4267CD7C.7000304@wstoddard.com>
Date: Thu, 21 Apr 2005 11:57:48 -0400
From: Bill Stoddard <bill@wstoddard.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: dev@apr.apache.org
Subject: Re: [WIN32] alternative apr_pollset implementation proposal
References: <HCEPKPMCAJLDGJIBCLGHGENFDOAA.james@wgold.demon.co.uk>
In-Reply-To: <HCEPKPMCAJLDGJIBCLGHGENFDOAA.james@wgold.demon.co.uk>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit

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