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 Sat, 21 Dec 2002 15:53:53 GMT
On Sat, 21 Dec 2002, Cliff Woolley wrote:

> On Fri, 20 Dec 2002 rbb@apache.org wrote:
>
> > 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.
>
> No it isn't, because if ap_pass_brigade() makes it all the way down to the
> core_output_filter, then after ap_pass_brigade_() returns, bb will have
> been destroyed by the core_output_filter.  I'm not necessarily saying
> that's *right*, just that that's the case today.

That would be a pretty massive bug.  I have both handlers and filters that
follow this pattern because it is supposed to work.  The reason it works
in my testing, is that _most_ of the time the core_output_filter doesn't
destroy that brigade.

    if (ctx->b) {
        APR_BRIGADE_CONCAT(ctx->b, b);
        b = ctx->b;
        ctx->b = NULL;
    }

This is where the magic happens.  If the filter has already saved aside a
brigade for this request (or a previous request in this connection), we
merge the two and drop the new one (a potential memory leak if not for
pools).

As I have said all day, a filter cannot keep or destroy a brigade that it
didn't create.  The creator of the brigade owns the brigade, and no other
filter can modify the brigade.  They can modify the buckets in the
brigade, but they can't do anything to the brigade itself.

Ryan


Mime
View raw message