Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 88758 invoked by uid 500); 28 Mar 2000 00:14:25 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk X-No-Archive: yes Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 88747 invoked from network); 28 Mar 2000 00:14:24 -0000 Date: Mon, 27 Mar 2000 16:19:11 -0800 (PST) From: Greg Stein To: new-httpd@apache.org Subject: Re: layered I/O (was: cvs commit: ...) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N On Sun, 26 Mar 2000, Greg Stein wrote: > On Sun, 26 Mar 2000 rbb@apache.org wrote: >... > > > Your sub-thread design for mod_include seems fine, but note that all > > > processors would need something similar. That general logic probably > > > belongs in src/main, with a registered callback to process blocks of data: > > > > 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. But after a bit more thinking, it is good to clarify something here. It seems there are two forms that processors could use: 1) A callback with chunks of data; the callback will typically use a state machine to process elements of the content 2) A sub-thread mechanism where the module will now read from a pipe instead of a file Option 2 has less impact on today's modules. Option 1 is (maybe?) less resource intensive since you won't have sub-threads. Cheers, -g -- Greg Stein, http://www.lyra.org/