Re: Chunked mempools, a first verdict

Andres Kroonmaa wrote:

> > No, it is probably a good name, but some stuff should probably move to
> > mem.c (maybe even all of it).
>
> Are you *sure*? I'd disagree, because stuff in MemPoolStats.c is very
> specific to current memPool implementation, while mem.c is somewhat
> free from specifics. Moving lots of stuff to mem.c will clutter it with
> stuff that someday may be changed alot.

The way to specific stuff should move into lib, with a suitable API that
is not soo specific.

> I'm in process of hiding most mempool internal funcs behind a Control
> function. Then I could move most of actual work to lib/ but we'd still
> need wrappers under src/ for what needs public declarations.
> I just wonder if that is a right path.

Same thing, different call method. Wait with that change. Having a
control function only complicates matters. Even if you have a control
function like that you still have an API of the same number of
functions, only thing changed is that you have hidden them behind one
object symbol name. In afct, as proposed the effect only is that you are
using one symbol more than if not having the control function (in theory
each macro also counts as a symbol, but is a bit harder to count with
automatic measures)

--
Henrik