httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: layered I/O (was: cvs commit: ...)
Date Tue, 28 Mar 2000 09:37:50 GMT
On Mon, 27 Mar 2000 wrote:
> > > > go take a look at mod_include, and tell me you can do this with no change.
> > > > if so then i'll be really impressed.
> > > 
> > > BTW, I worked it out earlier today, I can modify the currently working
> > > layered I/O code to require only two changes to current modules.
> > 
> > Do generators need to be changed? Or do just the processors need these
> > modifications?
> Generators and processors need to set the output BUFF, and some processors
> need to return STOP_HANDLERS.  Note, not all processors need modification
> (this doesn't include changes like the mod_include changes), only the
> processors that actually want to write to the network need to change.
> This should be http_core, and mod_ssl, AFAICT.

Hrm. Okay... not sure that I get this yet, but the code will explain it
quite well :-)

> > > 1)  They
> > > have to set the output BUFF correctly.
> > 
> > Would it be possible to have a function for this (to properly bundle up
> > the aspects of a layer), rather than direct manipulation?
> Sure, but it's a stupid thing to put behind a function, IMHO.  The
> function would basically take a request_rec and a BUFF *, and do:
> r->output = BUFF.

Um. How do you create the layering? This seems to be a single layer.

For example, I could see a situation where we wanted SSI to run, then PHP.
Let's just assume the source comes from a file. Files are handled by the
core, so the core handler is called and starts reading the file. It writes
the contents of the file using ap_rwrite(). The buffer is passed to the
SSI module. It does some various munging and passes its output to PHP. PHP
munges some more and its output goes to the client.

Note that SSI and PHP execute "asynchronously" to use Dean's term.
Otherwise, you would need a temp file or a big-ass memory buffer.

The call stack looks kind of like:

  ...:ap_layer_write   (maybe this is just ap_bwrite)

>From another note, it seems like you're defining r->input to be the source
("generator"), and one layer sets itself to be r->output. But it appears
each layer must remember the previous r->output, rather than having Apache
deal with the chain. I suggested the function because it seems Apache
would be handling the layering under the covers; the function hides the
magic that Apache is using (hooking into ap_rwrite and linking the layers

Also, to use the r->input scheme, this means certain content generators
(such as mod_dav) need to be rewritten to be callback-based.

I think there is a disconnect here somewhere... I'm seeing the
source/generator as driving the layers and the eventual network output. In
other words, the handler is called *once* and when it returns, the output
has been fully generated *and* processed.

It appears that in your model, the generator must create a BUFF (called
r->input). The processors can set r->output, but I'm not sure how they
layer. Then some code (where?) loops to read r->input and shoves that into
r->output. Is that right?

> > > 2)  Modules that write out to the
> > > network have to return STOP_HANDLERS.  Note, this is a change from what I
> > > committed.  
> > 
> > This is in reference to processors, correct? Could we just add a new hook
> > for them? Rather than using STOP_HANDLERS, the network-writer could just
> No, because which one is HOOK_REALLY_LAST?  http_core.c or mod_ssl?  One
> of these has to write out to the network, and if the data needs to be
> encrypted, it can't be http_core.  But if the data isn't encrypted, it has
> to be http_core.  See the problem with using HOOK_REALLY_LAST?  Depending
> on the request different hooks get HOOK_REALLY_LAST.

Fair enough. I retracted the hook idea anyhow because of the need to have
the layers occur in a more controlled/predictable fashion.


Greg Stein,

View raw message