Re: Chunked mempools, a first verdict

From: Alex Rousskov <rousskov@dont-contact.us>
Date: Thu, 3 May 2001 10:18:50 -0600 (MDT)

On Thu, 3 May 2001, Andres Kroonmaa wrote:

> > > extern int memPoolGetStats(MemPoolStats * stats, MemPool * pool, int index);
> >
> > Did you mean to have both "pool" and "index" parameters there? What is
> > the semantics of the return value? Sorry if it was documented before.
>
> Its somewhat loaded function again. Return value is either false (<=0)
> or index of a next pool (actually, "return index+1").
> If pool is not NULL, stats for only that pool are returned, by pool pointer.
> If pool is NULL and index is within 0...Array.count, stats for pool at
> given index is returned.
> Idea is to allow caller to iterate through all pools without knowing number
> of actual pools. Start from 0 up and continue until func returns false.

So what you really want is
        const int count = memPoolCount();
        while (int i = 0; i < count; ++i) {
                MemPoolStats *stats;
                memPoolGetStats(stats, i);
                ...
        }

Then, at least, you will not have to write/read so many words
describing what memPoolGetStats does (and that is always a good
thing). Moreover, I would even argue that

        MemPoolStats *stats;
        MemPool *p = memPoolAt(i);
        memPoolGetStats(stats, p);

is a better approach because most of your functions operate on MemPool
pointers, not integer indices. Also, you do not need any words to
describe this interface -- it is obvious from function profiles.
Finally, it makes the model closer to a true iterator ("int i"
semantics is almost opaque in the last example), which is good.

> > Also, it may be a good idea to have
> > memPoolGetStatsAll(MemPoolStatsAll*)
> > or some such because the internal routines may keep some global
> > statistics about all pools together (e.g., high water mark). You can
> > use that to get the count of existing pools for your iteration routine.
>
> Yes. Again a matter of additional exported symbols. Currently, to get stats
> for all pools I'd call memPoolGetStats(MemPoolStats *stats, NULL, -1);
> Which would internally iterate through all pools and generate summary
> stats. In place of pool->meter it then returns pointer to TheMeter which
> keeps global high water marks.

This assumes that MemPoolStats can express the summary statistics,
which is not necessarily true (in general or in the future).

I assert that we are after reducing the number of API elements (to a
necessary minimum), not function names! If f1() is different from
f2(), do not call both of them f(int i) just to please Henrik :-)

If the interface is so complex that it requires N elements, either
implement all N elements or simplify the interface. The number of
function names does not matter, IMO.

Thanks,

Alex.
Received on Thu May 03 2001 - 10:19:00 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:13:58 MST