Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Mon, 15 Jan 2001 09:29:49 -0800 (PST)
From: dean gaudet <dgaudet-list-new-httpd@arctic.org>
To: <new-httpd@apache.org>
Subject: Re: cvs commit: httpd-2.0 STATUS
In-Reply-To: <20010112123749.L4640@lyra.org>
Message-ID: <Pine.LNX.4.30.0101150920350.30402-100000@twinlark.arctic.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On Fri, 12 Jan 2001, Greg Stein wrote:

> apply to *all* output mechanisms (ap_r or buckets). Consider mod_include
> spitting out a bazillion little buckets (in a big-ass brigade, but small
> buckets nonetheless). Whatever is coalescing the ap_r buckets can apply to
> the mod_include buckets, too.

mod_include uses ap_rputs/printf.  fix those and you've fixed mod_include.
well at least mod_include in 1.3 did that, maybe you've broken it in 2.0
already :)

imnsho the primary problem is the dynamic generators which want buffered
i/o.  sure some filter can insert tiny buckets, but how about we see use
cases?  in general when i studied this problem years ago the filter use
cases i had could all be done in ways which were efficient.

remember many filters are complete transformations of their input and
derive no benefit from zero copy -- charset changes, compression,
encryption.  an oddball is chunking, but chunking, thank god, needs to
only insert one element per chunk.  this is what 2.0 did before you guys
ripped out my slick new BUFF code :)  1.3 inserts two elements per chunk.

then there's the mod_include style of filter -- which can totally use the
same heuristics that 1.3-BUFF used for buffering.  i.e. if it fits in the
current buffer then copy, otherwise form a two element writev of the
current buffer and the thing we're trying to bwrite.

so, what other use cases are there?

(if you dig through the archives you'll see i've said the same thing
before, and asked for more use cases and never gotten anything new.)

-dean