httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Finally found the problems. :-(
Date Sun, 31 Dec 2000 23:21:43 GMT

> > This is untrue.  After a BRIGADE_CONCAT, we do not need to destroy the
> > second brigade.  Brigades are allocated out of a pool, and they are very
> > small.  We are actually better off just letting the pool stuff take care
> > of this.  If we destroy the pool right away, we are just wasting time in
> > the middle of the request.
> If the brigade is created/concat'd within an unbounded loop, then we really
> ought to take the opportunity to toss it.
> Many allocations are one-time things and should use the pool. But if an
> allocation is related to the content, then we should be much more careful --
> we should proactively get rid of it.

We should not be trying to outsmart our allocation system.  Brigades are
incredibly small, specifically so that they can be allocated and just left
for the pools to deal with.  We are literally taking about a total of
three pointers.  We just don't need the added function calls associated
with destroying a bucket_brigade.  This requires that we kill a cleanup
that isn't going to do anything anyway.  The memory doesn't actually get
freed when we destory the brigade, and if the brigade has just be
concat'ed, then it is going to be empty.

Basically, what you are asking for, is to do always kill a cleanup that is
basically a no-op whenever we destroy a brigade.  There is no reason to do
this.  We don't free any memory, because the memory is allocated out of a
pool, and we never free memory from pools.  If we call destroy_brigade
whenever we concat, all we are doing is searching a linked list and
calling a function that is essentially a no-op because the brigade is

This doesn't need to be done, and it shouldn't be done.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message