Re: TLV to memPools

Andres Kroonmaa wrote:

> String functions use mem.c:memAllocBuf, which is purely variable sized
> allocator.

Implementation is, actual usage is not..

> Basically what I asked is why memAllocBuf has String.c oriented checks
> while looking like general thing. To me, memAllocBuf has nothing to do
> with Strings other than pool names. Its very binary.

It has the quite strong connection to String.c in that it is only
String.c which uses it. It was written for String.c, and the API hasn't
been reviewed for usefulness outside String.c.

> It could be used everywhere where alloc size is known at both alloc
> time and free time, like is the case with TLV.

I agree that there is need for a good "malloc()" replacement of untyped
data. However, it is not clear to me where the proper balance is in this
case.

Things which need to be considered
  * Overhead in CPU
  * Overhead in memory usage
  * Robustness to coding errors
  * Robustness to code changes
  * Ease of coding

The balance between these varies for different types of data. For most
cbdata the balance is very strongly biased to the two robustness issues.
For TLV the requirements is different. In fact, the requirements are
different than from any other allocations we have as these are abstract
typed allocations.

Thinking about TLV's I am not even sure I like the current
implementation. I don't see a need of packing/unpacking these at all.
When constructing the list do so directly in binary form in a MemBuf.
When unpacking, make a iterator who can iterate over the packed buffer
and return the components as needed (with no copying). Why have the
intermediary abstract binary format of linked lists at all? It is not
like we need or should manipulate lists of TLV's.

Regards
Henrik
Received on Tue Oct 09 2001 - 03:23:03 MDT