Re: [squid-users] Memory pools: why use them?

On Wed, 2004-09-01 at 18:58 +0200, Henrik Nordstrom wrote:

> > Actually, I was thinking the other way around: the 3.0 MemPools support
> > multiple pool allocators: so we can have a trivial pool that is just
> > malloc/free always compiled in and available. Then in squid.conf. the
> > disable_mempools command goes away, and instead we change the default
> > implementation - possibly in squid.conf, but more likely a one line
> > change in MemPools.cc.
>
>
> If you ask me this kind of configuration belongs at compile time. I see no
> value of having a squid.conf directive for selecting which "malloc"
> implementation to use.

I'm still undecided-in-my-own-head....
There are three reasons I think it is useful to have such a thing
selected at runtime:
1) If a suspected memory-corrupting bug is found in production, you can
easily switch to the native memory allocator, or to one that uses
free/alloc and is thus trackable by valgrind etc. Importantly you can do
this even for systems running binaries without source experience. So we
can get better bug reports.
2) different alloc strategies may make better sense for different
classes. i.e. memory buffer classes may make sense as a direct
alloc/free with caching, disk buffer classes may make sense as
alloc/free with no caching and everything else via a slab allocator.
Having multiple strategies available at runtime lets us do this in a
clean manner.
3) different loads on a proxy may give us reason to switch strategies
without taking the proxy down - this would require a more advanced
implementation again - but could be done.

Rob