httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: Filter I/O take 3.
Date Fri, 16 Jun 2000 21:40:05 GMT
On Fri, Jun 16, 2000 at 02:44:56PM -0000, Jeff Trawick (httpd) wrote:
> > 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

The pull vs push is what I meant by "flipping." The async model is pull.
Apache is built entirely around push.

> 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.

Yah, that is what I surmised. Apache simply cannot do async output. Its
entire processing model is built around calling to a module and having that
module call ap_rwrite() as it goes.

Take my favorite example for a content-generator: mod_autoindex. Examine the
emit_link() function and how it calls ap_rvputs(). If that blocks, then what
do you do? The thread simply blocks... there isn't a way to do async I/O.

> 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.

We're already there :-)

> 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).  

Can't do this either. Consider the various calls to ap_get_client_block()
which are (again) scattered down "inside" modules which then rely on
context which is defined by the stack.

Apache moving to an async model simply looks impossible, without a **HUGE**
overhaul in every facet of its operation. At that point, it just won't be
Apache. I could see a case where a module can say "I can deal with async;
here is my API to call for read/write availability." To support that,
though, would still require a huge revamp on the Apache-side of the equation.


Greg Stein,

View raw message