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/[EMAIL PROTECTED]
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
