Re: Chunked mempools, a second verdict

Andres Kroonmaa wrote:

> you mean use of them is optional? setChunkSize can always be, but
> for idle_limit we'd need then hardwire some default.

Fine.

> As it is currently, it is somewhat clumsy to determine NextPool
> based on *prev_pool. Would require linear search.

Using a iterator is probably better.

> 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?

Which worries me a little. There may well be other MemPool operations
while iteration, especially Create.

[about iterator]

> Why would that be good? (I've not seen something like that yet)
> Sounds complex to me. At least not intuitive.

A similar technique is used in the removal policy API to enumerate the
objects in the policy.

As Aliex said it is plain OO methology applied to C, but this time
avoiding the complexity of a call table..

In C it looks like

  MemPoolIterator *iter = memPoolIterate();
  MemPool *pool;

  while (pool = memPoolIterateNext(iter)) {
     /* Do what is required on pool */
  }
  memPoolIterateDone(&iter);

In C++ it would look like

  MemPoolIterator *iter = new MemPoolIterator();
  
  while (MemPool *pool = iter->next()) {
     // do what is required on pool
  }
  delete iter;

or simplified using a local/auto object

  MemPoolIterator iter();

  while (MemPool *pool = iter.next()) {
     // do what is required on pool
  }
  
> 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.

Should be part of the normal maintenance/housekeeping I think. No need
for a separate call.

> > Cut. Use current_dtime or a similar global variable.
>
> As it is done now? This kind of violates the goal for the library
> to be independant of the source it is used with. But its simplest.

Exacly.

> ok, I'll hide the Init call.

Fine.

> in mem.c Short/Medium/Long Strings_pools are handled via memAllocBuf().
> It uses same Meter types and same macros for updating. memMeterSyncHWater()

So both MemPool and mem.c are using the MemMeter type for
accounting/statistics?

If so then MemMeter should be separated from MemPool, with it's own API
definition. (simply move it to a separate include+c file, and document
it in Programmers Guide). Or if you do not want to make an API of it,
duplicate the structs+macros in both MemPool.c and mem.c.

And beware of overuse of macros in API definitions. macro expressions
can cause very subtle bugs when the macro is used in a sligthly differen
context than originally thought of. For example
   memMeterSyncHWater(meter[i++]);

--
Henrik