> From: Bill Stoddard [mailto:[EMAIL PROTECTED] > 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" <[EMAIL PROTECTED]> > To: <[email protected]> > 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
