httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject brigade cleanup (was: Re: Finally found the problems. :-()
Date Sun, 31 Dec 2000 23:41:01 GMT
Ah. My mistake... I thought brigade structures were malloc'd. If they're
from a pool, then we have problems (see below). Also, presuming that we make
them mallocs, then we need to be proactive (see below).

On Sun, Dec 31, 2000 at 03:21:43PM -0800, rbb@covalent.net wrote:
>...
> 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.

Three pointers multiplied by the content-size of the response is too big.
Heck, one byte in proportion to the content-size is too big.

Like I said: if a brigade is created in proportion to the content-size, then
it must be destroyed.

If the brigade is created as a fixed count per response, then yes: leave it
for the pools.

But that fixed vs proportional is important... proportional a Bad Thing(tm).

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

Yes, the brigade will be empty, so no worries in terms of buckets.

I think the problem is that the brigade itself is allocated from a pool. As
you say: that means we can't toss it after a concat. It would seem that we
should reconsider allocating brigades from pools.

[ specifically: consider that ap_r* creates a new brigade each time they are
  called. this means the number of brigades is proportional to the content
  size. we must be proactive in clearing them out ]

In summary:

1) don't use pool allocations for brigade structures. Use malloc and a
   tricky cleanup (we can't use a dumb cleanup because then we're doing a
   pool-alloc (for the cleanup info) for every brigade creation again).

2) call ap_brigade_destroy() when we're done with a brigade

[ we don't need to be as careful with destroying brigades that are fixed in
  count. the pool cleanup will toss those. ]

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message