httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Trawick \(httpd\)" <>
Subject Re: Filter I/O take 3.
Date Fri, 16 Jun 2000 14:44:56 GMT
> Date: Fri, 16 Jun 2000 07:27:34 -0700
> From: Greg Stein <>

>           I presume for an async I/O approach, you would need to flip
> this around where the network layer says "I'm ready for more" and "pulls"
> content. Is my read on the situation correct?

(I'm only familiar with async I/O on OS/390, but I would hope it works
similarly on other platforms.)

I don't see it as flipping it around.  Instead it is more like
multiplexing the work of sending data on multiple sockets using select
and non-blocking sockets.  You do what you can on one socket (without
blocking) and move on to the next socket.

With asynch I/O, the program issues a request (consider just read/write
for now) and can then go about its business (but not touching the
buffers handed off to the request) until at some later time the system
notifies the program that the request is complete.

If we're in an output pipeline and we get to the point of doing a
write to the TCP stack and we make the request async, we just need to
save our state (in a way that any other thread in the process can pick
it back up when the I/O is complete) and see if there is work on
another connection for us to carry forward before we go to sleep.

Depending on where state is saved and buffers are handled and how you
choose to switch the context from one connection to another, async I/O
may or may not be broken.  If state (and I/O  buffers) live on the
stack, that places some extreme (perhaps fatal) limitations on how the
state of one connection can be saved for picking back up later.  This
is more to say that it can be done in a way that allows async I/O to
be done.  I don't think we would want to get in a position where we
were forced to use a user-level thread package to make it work.

Note that various folks have pointed out that doing async I/O only on
read (and perhaps only when reading/waiting for the first header of a
request) brings a lot of bang for the buck (I don't mean that
literally, Ralf).  

(anybody got a sig I can have?)

View raw message