httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: layered I/O (was: cvs commit: ...)
Date Tue, 28 Mar 2000 00:56:50 GMT

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

> btw, it seemed from one of Ryan's posts that my differentiation wasn't
> clear. A "generator" is probably best described as a "source". The
> generator pulls the content off the disk, out of a database, via a CGI,
> etc. Next, processors are applied. These are the "layers". For example,
> mod_include processes the input and spits out something to the next layer
> (or the network if no layers).

This is done behind the scenes now.

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

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

> Thanks for the renewed look at this stuff, Ryan!
Always willing to work to get my patches in.  :-)


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message