Hi, Just raising this again. This time I'll ask differently: Is anyone opposed to adding this? [feedback please]
I know Ian wants this badly. I can go either way. I would really like to see some perf comparisons with and without it to see if it doesn't do too much damage to performance (or if it does at all in a measurable fashion). Sander > From: Sander Striker [mailto:[EMAIL PROTECTED] > Sent: 21 March 2002 09:13 > > 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 >
