httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bri...@apache.org>
Subject Re: Deleting the async-dev branch
Date Mon, 21 Nov 2005 01:43:41 GMT
On Nov 20, 2005, at 1:34 PM, Phillip Susi wrote:

> Actually you have to use a peg revision, not -r.  If you try -r to  
> look at the deleted branch, svn tries to find the named directory  
> in the HEAD revision, then look up it's state as it existed in rev  
> x.  This will fail since it does not exist in the head revision, so  
> instead you have to do something like:
>
> svn list http://repos/svn/deleted@x
>
> svn list -r x http://repos/svn/deleted fails because deleted does  
> not exist anymore.
>
> By the way, what exactly is the async-dev branch and what are the  
> future plans for it?  I actually have spent this entire weekend  
> doing research on the current state of support of async IO in linux  
> and modified the dd program to use overlapped async IO when you  
> pass it the iflag=direct option.  It turned out that glibc's posix  
> aio library simply performs sync IO in a background thread, so I  
> ended up hacking together a basic aio implementation that directly  
> uses the kernel's aio support.  I'm still testing it but it looks  
> like it yielded substantial cpu savings and throughput increases by  
> keeping the drive directly reading into the userspace buffers.  DMA  
> transfers sure beat memcpy()s.
>

The async-dev branch was a place for testing changes to the httpd  
core and
Event MPM to support nonblocking network writes.  These changes have  
since
been merged into the httpd trunk.  Once the entire response for an HTTP
request has been generated, the worker thread hands off the remainder of
the response transmission to a central pollset.  The new async-read-dev
branch is something I just created as a sandbox for developing  
nonblocking
network read support.

The async write completion stuff that's now in the trunk does  
nonblocking
network writes, and it uses sendfile to do zero-copy transfer from  
the filesystem
cache to the network on platforms that support it, but it doesn't try  
to do file
I/O asynchronously.  Thus it's possible for the current code to block  
on a
disk read while trying to do a nonblocking socket write.  (The Event MPM
compensates for this by allowing multiple threads to do sendfile  
calls on
different sockets concurrently; if one thread happens to block on a
physical disk read, it doesn't delay other connections.)  Having a means
of doing nonblocking filesystem I/O, via either aio or something like
mincore checks, might be a nice addition.

Brian


Mime
View raw message