On 8 Oct 2001, at 9:32, Adrian Chadd <adrian@squid-cache.org> wrote:
> > Any good reason why we insist on size to be exactly size of
> > pool's obj_size?
> >
> > /* free buffer allocated with memAllocBuf() */
> > if (size <= StrPoolsAttrs[i].obj_size) {
> > >>> assert(size == StrPoolsAttrs[i].obj_size);
>
> Hrm. Size and therefore pool predictability?
>
> Hrm. Isn't there some general type API for this? Perhaps
> in the string code? If not, you could whip up an API to do it.
> I think thats something that may make things .. nicer.
>
> Yes, something like this
>
> struct memblock {
> char *buf;
> int size;
> pool_t pool;
> int allocated;
> };
>
> then, something like:
>
> MEMBLOCK_PTR(memblock *) to get a char * or void * pointer to the memblock
> MEMBLOCK_SIZE(memblock *) to get the max size (think string manipulation..)
> memblock_alloc(memblock *, size) to allocate some RAM to the thing
> memblock_realloc(memblock *, size) to reallocate some RAM to the thing
> memblock_free(memblock *) to free the memblock
> memblock_init() / memblock_done() to setup/delete the pools
>
> This way, the memblock* routines can then decide which pool to stick
> the data in and tuck the pool pointer away for future reabuse
> when reallocating (allocate new blockin a new pool, memcopy, free
> old one).
>
> Instead of a
>
> char *buf; /* some buf */
>
> in a struct or function decl, they could have:
>
> mempool_t mempool;
>
> note that I'm using a static struct rather than a pointer - there's
> no point in pooling the mempool_t entries, as they're minimal and
> this would cut down on allocator overheads.
the problem is that we too often need to pass buf as single pointer
to some API together with freefunc. so we'd need to pass *mempool
and change alot of how its referenced.
Imho, closest to whats needed is cbdata with its hidden preamble.
If we extend it to include pool obj_size, and/or add a special alloc
type "bestfit" upon which cbdata picks most suitable pool for req,
we'd be cool, as upon free we can find right pool from cbdata.
On other hand, this makes you think why we convert all stuff to
pools in first place. One major goal is performance, which may
suffer if this kind of allocation becomes too popular. Other goal
is least memory overhead, which also suffers.
------------------------------------
Andres Kroonmaa <andre@online.ee>
CTO, Microlink Online
Tel: 6501 731, Fax: 6501 725
Pärnu mnt. 158, Tallinn,
11317 Estonia
Received on Mon Oct 08 2001 - 10:47:02 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:14:26 MST