apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: [PATCH] Maximum free memory in an allocator OR: hifree, revisited
Date Thu, 21 Mar 2002 08:13:22 GMT
> From: Bill Stoddard [mailto:bill@wstoddard.com]
> Sent: 19 March 2002 21:36

> This could be quite useful for mod_*_cache.  What triggers the free?

The free is triggered on either apr_pool_clear or apr_pool_destroy,
when the blocks in the pool are returned to the allocator (using
apr_allocator_free()).  When adding a block to the freelist causes
the freelist to be larger than then threshold (set with 
apr_allocator_set_max_free()), the block will be free()d instead
of added.

The default is to have max_free be 0, which translates to unlimited,
which is the current behaviour.

Ofcourse this patch will come at a small performance penalty, but
I'm not sure if it is measurable.
 
> Bill

Sander

> ----- Original Message ----- 
> From: "Sander Striker" <striker@apache.org>
> To: <dev@apr.apache.org>
> Sent: Tuesday, March 19, 2002 2:45 PM
> Subject: [PATCH] Maximum free memory in an allocator OR: hifree, revisited
> 
> 
> > Hi,
> > 
> > Keep getting the question if the hifree patch is
> > going in.  So, decided to revisit that patch and
> > implement it now we have the allocators.
> > 
> > For those who didn't follow that thread:
> > This patch allows the programmer to set a maximum
> > amount of free bytes allowed on the allocators
> > freelist.  Anything over it will be free()d back
> > to the system.
> > 
> > Thoughts?
> > 
> > Sander


Mime
View raw message