> From: Brian Pane [mailto:[EMAIL PROTECTED] > Sent: 07 February 2002 04:21
>> It is the memory on the freelists that grows without bounds. The patch >> free()s memory that is added to a freelist when the freelist already >> holds a certain amount of free memory. This is very usefull when you >> have peak memory usage as some people pointed out. >> >> The pools model is something you are stuck with it if you want to use APR. >> And it is not always pools abuse which gives you big chunks of mem on >> the freelist. Although I must admit that I would recommend some >> serious review of the code which shows this behaviour. >> >> Anyhow, I'd like to add a configure option which you can feed the >> amount of memory you want as a maximum on a freelist, defaulting >> to infinite. >> >> Thoughts? >> >> Sander > > I like the idea of a configurable maximum. It probably should > be run-time configurable rather than build-time configurable, > though. It would be even better if the max free list size could > be specified on a per-allocator basis, so that the application > developer could tailor the properties of each free list to the > needs of the app. > > --Brian That certainly can be coded up. We only need to think about an API. Currently I am playing with the idea to factor the allocator out, and expose it. This would give us the opurtunity to add a set_max_free function in there. Placing it in the apr_pools namespace is something I'd rather not do. Sander
