Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Mon, 27 Mar 2000 14:09:45 -0800 (PST)
From: Dean Gaudet <dgaudet-list-new-httpd@arctic.org>
Sender: Dean Gaudet <dgaudet-list-new-httpd@arctic.org>
To: new-httpd@apache.org
Subject: Re: layered I/O (was: cvs commit: ...)
In-Reply-To: <Pine.LNX.4.10.10003261314030.9746-100000@nebula.lyra.org>
Message-ID: <Pine.LNX.4.21.0003271405140.14812-100000@twinlark.arctic.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

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.

> The content-processors would need to change the following kind of loop:
> 
>   content-handler:
>     fd = open()
>     while 1:
>       data = read()
>       if not data:
>         break
>       process_data(data)
> 
>   process_data(data):
>     ...
>     ap_rputs(monkeyed_output)
>     ...
> 
> to:
> 
>   some-hook-function:
>     register_processor(process_data)
> 
>   process_data(next_layer, data):
>     ...
>     ap_layer_puts(next_layer, monkeyed_output)
>     ...
> 
> I don't see a big change in the content-processors either.

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.

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

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

Dean