Re: Chunked mempools, a second verdict

On Fri, 4 May 2001, Andres Kroonmaa wrote:

> > extern MemPool * memPoolGetFirstPool(void);
> > extern MemPool * memPoolGetNextPool(MemPool *previous_pool);
>
> As it is currently, it is somewhat clumsy to determine NextPool
> based on *prev_pool. Would require linear search.

Not necessarily:
        - one can store pools in a linked list in addition to
          or instead of the current array
        - once can cache last pool position because in 99% of
          cases memPoolGetNextPool() calls will be sequential

There are probably other ways to avoid linear search.

> We would like to ignore *previous_pool initially.
> With a guarantee that after First(), Next() would iterate through
> all pools, as long as First,Destroy,Create is not called?

That would be bad because somebody will eventually write a loop with a
"break" or "return" statement inside and cause hard-to-find bugs. Perl
has this misfeature for operator called "every", and its a very common
bug to misuse it.

> > or even one using a abstract iterator type
> >
> > extern MemPoolIterator * memPoolIterate(void);
> > extern MemPool * memPoolGetNextPool(MemPoolIterator **);
> > and optionally (in which case one * above goes away)
> > extern void memPoolIterateDone(MemPoolIterator **)
>
> Why would that be good? (I've not seen something like that yet)
> Sounds complex to me. At least not intuitive.

It is a standard OO iterator, converted to C. I agree that it looks
more complex in C. The real advantage of those things is that you can
pass an iterator to a third function (algorithm), and that function
would iterate "anything" doing "something" on it. You will not see
many of such things in Squid yet, but it is a standard STL technique.
As you know, I stopped short of proposing this; I was afraid to be
pummeled for forcing OO/C++ ideas onto Squid code.
 
> > > extern void memPoolCheckRates(); /* stats history checkpoints */
>
> see my other post about perpool alloc rates/sec column in cachemgr.
> currently, memReport is modifying memMeter structs it receives from
> memPoolGetStats(), by copying current counter aside. This call is
> meant to ask the library to do that internally for us.
> To maintain historical stats outside the pool itself would be
> trouble, and no easy way to get notified when pool is destroyed.

Still not sure why do you need this call. Why can't the library do it
on its own, when needed (either via memPoolUpdateTime that Henrik
banned or from inside of other public functions).

> I'm not sure if these other strings have ever seen a single hit.

And you would have no way to find out if they did not have stats
attached. :)

Thanks,

Alex.
Received on Thu May 03 2001 - 17:30:35 MDT