Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <5.1.0.14.2.20021220210146.024d58d8@pop3.rowe-clan.net>
Date: Fri, 20 Dec 2002 21:09:04 -0600
To: dev@httpd.apache.org
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: Re: [PATCH] Update to Brian's patch to allocate brigades out
  of the bucket allocator
Cc: rbb@apache.org, dev@httpd.apache.org,
        APR Development List <dev@apr.apache.org>
In-Reply-To: <1040437983.2506.12.camel@desktop>
References: <Pine.LNX.4.33L2.0212201345550.17851-100000@vangogh.rkbloom.net>
 <Pine.LNX.4.33L2.0212201345550.17851-100000@vangogh.rkbloom.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 08:33 PM 12/20/2002, Brian Pane wrote:
>On Fri, 2002-12-20 at 13:50, rbb@apache.org wrote:
>
>> > Basically, if you received a brigade from a higher filter, you can only
>> > assume that it will survive a single trip down the filter stack.
>
>Right.  And you also can't assume that the context that passed
>the brigade down the filter stack still exists by the time the
>brigade reaches the last filter.  It's a safe assumption in
>httpd-2.0, where the brigade is passed as a synchronous function
>call, but it's not valid for apps in general (potentially including
>future Apache versions) where the brigade may be queued up for
>asynchronous processing by an I/O completion thread.

No, it simply will have to be valid.  Not that the context will be
bound to a specific thread (it won't), and not that the content will
be living in a given context.

However, if the core output filter *chooses* to set aside the brigade
list (not the data, remember, but the brigade list itself), then it will
have to have some context to stash that in.  So we will end up with
n connections and no less than n pools.  But we may only service
those pools with n/4 threads, depending on the economies.

If we are changing ownership assumptions, that breaks existing
modules.  If we are breaking 3rd party modules, we are back to the
2.x debates.  However, the scope of this change requires that the
old code is broken.

So that leaves us with the obvious course, if we are going to start
rethinking this from scratch (I don't see a reason too, but...) it better
be with the newer version only (way too many segfault reports this
week from all corners.)

Bottom line, we can't break it till we push out APR 1.0.  This leaves
a very useful question.  Do buckets/brigades remain in apr-util with
the release of 1.0?  We've just proven that the concept is both very
apr and very httpd centric.  There is no reason we should burden
apr with the 'learning curve' of redesigning this code.

I suggest we consider the benefits of pulling buckets/brigades from
apr-util with the 1.0 release of the apr library, and move that code 
back into httpd if we plan to keep abusing it this way.

apr and apr-util should be repositories for proven concepts, if not
always proven code.  If we are still redesigning, something is wrong.

Bill