On Tue, 2004-08-31 at 17:13 +0200, Henrik Nordstrom wrote: > On Tue, 31 Aug 2004, Matus UHLAR - fantomas wrote: > > > in what way? to have that behavior permanent, or to keep things at library > > malloc? Does squid handle its memory in such efficient way that using > > malloc/free would have strong performance impact? > > Just to take away the "memory_pools on/off" configuration directive as it > does not make much sense to have this direcive. The configure > --disable-mempools directive is sufficient and serves a real purpose. > > The main reason why the configuration directive exists is to initially > make it easier to proof that the use of memory pools do make a benefit. > This is already well proven. In fact the configuration directive probably > should had gone away even before the first STABLE release with memory > pools support, remaining only as a configure --disable-mempools directive. > > The --disable-mempools configure directive is still needed, but for other > reasons (debugging).
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. Rob
signature.asc
Description: This is a digitally signed message part
