httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: RFC: Who owns a passed brigade?
Date Mon, 25 Apr 2005 13:29:46 GMT
On Fri, Apr 22, 2005 at 04:42:04PM -0500, Rici Lake wrote:
> 
> On 22-Apr-05, at 9:32 AM, Joe Orton wrote:
> 
> >The issue here is really "which party can *destroy* a brigade", right?
> 
> Or perhaps "which party *must* destroy a brigade." This is much less of 
> an issue if neither party creates a new brigade on every filter 
> invocation. But some do.

Yup, the "must" is the key, actually making this an interface
guarantee...

> >In the current code where brigades are never really destroyed the fact
> >that apr_brigade_cleanup() is called everywhere is not really harmful,
> >is it?
> 
> No, what would be harmful would be apr_brigade_cleanup() not being 
> called on a non-empty brigade.

I think it's fine to leave the *contents* of the brigade as undefined
after a call to ap_pass_brigade.  (that's essentially the case now since
it's not explicitly defined to be "empty": I don't know of any
particular bugs which have been caused by this?)

Any filter which passes a brigade can know that it *must* clear the
brigade before reusing it.  If the brigade is never re-used, it never
need be cleared before it's destroyed; no harm done.

So is there any disagreement at all about moving to the "creator must
destroy the brigade" model?  If not, I'd suggest moving forward like
this:

1. update the util_filter.h documentation
2. add some APR_BUCKET_DEBUG code to abort() when brigades are used 
after being "destroyed"
3. adjust all filters to work with this model
4. switch to allocate brigades out of the bucket allocator
5. profit (aka. closing all the memory leak bugs caused by this stuff
in bugzilla)

joe




Mime
View raw message