httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: brigade patch, last time.
Date Sat, 27 Jan 2001 17:42:40 GMT

Let's compromise.  :-)  See below for my idea.

> 1) large writes consume large amounts of working set (copy into a bucket)
> 2) medium-ish writes cause extra copies (anything larger than 9k cause an
>    extra copy to the heap, rather than delivery down the chain)
> 3) two ordering problems: within the brigade, and between ap_r* and
>    ap_pass_brigade.

The problems you have with 1 are decisions made, not design.  So let's
ignore those.  2 is also a decision, not a design flaw.  3, we disagree
about.  Since the only thing that really matters is 3, lets focus on
that.  BTW, when I say decision, that basically means that there were two
options.  I chose one.  I had a reason, whether good or bad, it was a
decision made.  Once this is committed, we can re-visit those decisions
and come up with a consensus.

cases B & C are the two that deal with issue #3 above, so lets focus

> B) The use of r->bb is always going to cause an ordering problem between
>    ap_r* and ap_pass_brigade.
>    Answer: The only solution I see there is to teach ap_pass_brigade about
>            r->bb. Not sure how I feel about that.

Let me give another option.  Stop using your own brigade in handlers.  If
you are re-writing your handler to use brigades, you have two options, use
your own brigade, or just use r->bb.  If you use your own brigade, then
you had better be sure that r->bb is never used, or that you account for
it.  The core shouldn't have to deal with that.

> C) Lastly, the ordering problem within the brigade will continue as long as
>    the buffer is stored outside of the bucket list.
>    Answer: using a buffer bucket (or an overallocated heap bucket) solves
>            this one.

I disagree about this.  We are dealing with buffering here, and going from
buffered to non-buffered ususally requires that the programmer get
involved.  I also have a problem with the definitions, buckets have been
defined to be read-only, we are about to create a bucket that is
read/write.  I worry about confusion at that point.  I also worry about
how complex the code will need to be, since I have written this code once

> So... if we can agree on (C), then I see the light at end of the tunnel. The
> rest is all doable.

So, here is the compromise.  I will re-write the code tonight to use a
bucket for the buffering.  This removes the mode.  I would ask you to
accept that we can help programmers who use their own brigade and ap_r*
functions.  Those people need to be responsible for their handlers, and we
will document that handlers can, and in fact _should_, use r->bb as their

If this is acceptable to everybody, I will fix the code tonight, and
commit today.  This lets us work on fixing any bugs or change decisions
over the next week or so.  As soon as i see 3 +1's, I will write the code
and commit.  If I get the 3 +1's today, then you can expect the commit to
happen about 10:00 tonight.  BTW, I believe this should happen before any
kind of beta, because this fixes performance for a filters as well as
handlers, and it allows us to simplify the header handling a bit more.


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

View raw message