apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@apache.org>
Subject Re: [PATCH] Update to Brian's patch to allocate brigades out of the bucket allocator
Date Fri, 20 Dec 2002 21:50:21 GMT
On Fri, 20 Dec 2002 rbb@apache.org wrote:

> On 20 Dec 2002, Brian Pane wrote:
>
> > On Fri, 2002-12-20 at 08:57, rbb@apache.org wrote:
> > > I am actually pretty sure that allocating brigades out of the
> > > bucket_allocator is a VERY big mistake.  In fact, I am close to asking
> > > that change to be backed out because it is too dangerous.
> > >
> > > When we first designed buckets and bucket brigades, we made one VERY clear
> > > distinction.  Bucket_brigades are allocated out of a pool, because that
> > > stops us from leaking memory.
> >
> > Allocating brigades from a pool is often a design mistake.
> > Brigades tend to outlive the transactions that produce
> > them (especially in apps like http servers), and having a
> > brigade disappear as a side-effect of a transaction pool's
> > cleanup will cause problems elsewhere in the code.
>
> Ummmm, I don't believe that it is possible for a brigade to outlive the
> transaction that created it, especially not when you look at how brigades
> are used in the web server.  Basically, a handler creates a brigade and
> passes it down the filter stack.  Each filter in the line is then allowed
> to either concatenate that brigade to it's own brigade or keep sending it
> down the stack.  At the bottom of the stack, the brigade must have been
> generated out of the connection pool, which by definition lives as long as
> the transaction that created it.
>
> 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.  That is
> why all filters must create their own brigade to save data between calls.

Just to be very clear about why this true.  Imagine a handler that does
this:

apr_brigade_create(bb, ...);
fill_brigade_with_data(bb, ...);
ap_pass_brigade(bb, ...)

ap_clean_brigade(bb, ...);
fill_brigade_with_more_data(bb, ...);
ap_pass_brigade(bb, ...);

This is perfectly legal for a handler to do.  However, this means that any
filter that wants to save the data in this brigade for use later, must
copy the buckets to their own brigade.  If they try to just save a pointer
to the brigade, they won't have the data they expect on the second call.
The brigade will still exist, but the data will be wrong.

For this reason, all filters must move the buckets to their own brigade,
which means that a brigade cannot outlive the transaction that it was
created for.  Essentially, the filters mitigate the brigade lifetimes.

Ryan


Mime
View raw message