httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: layered I/O (was: cvs commit: ...)
Date Mon, 27 Mar 2000 23:20:36 GMT
On Mon, 27 Mar 2000, Dean Gaudet wrote:
> On Sun, 26 Mar 2000, Greg Stein wrote:
> > I don't believe that the content-generators need to be changed AT ALL.
> > They would continue to call ap_rput*() as they do now.
> 
> then you haven't thought on it hard enough.

That is why I posted. I'd thought enough about it to know that the initial
design wasn't as good as it could be, but I didn't have the full story
either.

>... pseudo-code ...
> that's a massive change to the content-processor!
> 
> you've just made it so that the content-processor *can't use the stack to
> store any context*.  all the context has to be moved to a structure which
> is used by each call to the process_data function.
> 
> 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.

Dude. Read my statement closer, rather than being confrontational.

I said: no changes to the content-GENERATORS.

I said: changes would be necessary to the content-PROCESSORS.

Your point is valid -- the processor changes are larger than my note
implied. I did understand that processors would generally need some kind
of state machine to deal with symbols/whatever that cross callback
boundaries.

Looking at mod_include: yes, it would take a big change, *if* you used the
callback mechanism. Ryan's sub-thread mechanism changes mod_include very
little -- the sub-thread runs send_parsed_file() and blocks on a pipe,
while the parent stuffs the pipe with data from the callback.

To be most efficient, mod_include could be changed into a tokenizing
parser. As each complete token comes in (via the callback), it drives some
output or grammar element.

> gah, you know -1s coming from folks who haven't worked out this problem
> are totally annoying.

Bite me. You're being totally confrontational here, and it isn't called
for. You didn't read my statements. I said no change to generators, and
definite changes to processors.

I will take the very valid criticism that I did not make it clear just how
much processors would change. The sub-thread / pipe means they don't have
to change much, or it could be a lot if they directly use callbacks.

But to call me annoying is out of line. I know enough of what I'm talking
about to recognize that the initial design could be much better. I posted
my thoughts because I also knew that I didn't have a complete and proper
design either. IMO, that is how things should operate, and you shouldn't
be calling me anything.

> > > No, the sub-thread design is a hack just to get it to work.  The
> > real way > this should be done, is to re-write mod_include to deal
> > well with > streaming data coming from the BUFF structure.
> > 
> > We agree on this at least :-). This was the rest of my email comments.
> 
> wow, you agree that content-processors require massive changes... above
> you claimed no changes would be required.

No changes to generators. Go read it again.

Ryan's initial design had a similar requirement on the processors, but
also had changes to make against the generators.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/



Mime
View raw message