Re: [PATCH] Update to Brian's patch to allocate brigades out of the bucket allocator

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

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

Re: [PATCH] Update to Brian's patch to allocate brigades out of the bucket allocator

[Justin Erenkrantz <je...@apache.org>]

--On Friday, December 20, 2002 9:09 PM -0600 "William A. Rowe, Jr." 
<wr...@rowe-clan.net> wrote:

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

Serf uses buckets and brigades.

While I know that Cliff, Aaron, and Greg keep mumbling about 
rewriting buckets/brigades solely for serf, they've done nothing so 
far.  I don't think we even came to an agreement on how to model it 
correctly.

So, if you yank buckets from apr-util right now, serf is in a world 
of hurt.  I'd probably be forced to duplicate the code to get it to 
build again.  Ick.  -- justin

Re: [PATCH] Update to Brian's patch to allocate brigades out of the bucket allocator

[rb...@apache.org]

On Fri, 20 Dec 2002, William A. Rowe, Jr. wrote:

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

Please read my response to Brian, it isn't a valid assumption in
httpd-2.0.

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

I consider this an incorrect statement.  New concepts should be welcome
anywhere.  My question is more basic.  Is the bucket/brigade concept
useful outside of the web server/web client libraries that are being
discussed?  If so, then they should stay where they are.  If not, then
move 'em back into the httpd project.

Of course, I don't believe that apr-util is a useful library currently, so
that could be why I am against keeping buckets and brigades in it.  That
library won't be useful until it has more holding it together than "These
are concepts that were useful in Apache, so we exported them".

Ryan

Re: [PATCH] Update to Brian's patch to allocate brigades out of the bucket allocator

[rb...@apache.org]

On Fri, 20 Dec 2002, William A. Rowe, Jr. wrote:

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

Please read my response to Brian, it isn't a valid assumption in
httpd-2.0.

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

I consider this an incorrect statement.  New concepts should be welcome
anywhere.  My question is more basic.  Is the bucket/brigade concept
useful outside of the web server/web client libraries that are being
discussed?  If so, then they should stay where they are.  If not, then
move 'em back into the httpd project.

Of course, I don't believe that apr-util is a useful library currently, so
that could be why I am against keeping buckets and brigades in it.  That
library won't be useful until it has more holding it together than "These
are concepts that were useful in Apache, so we exported them".

Ryan