apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Knight <christopher.d.kni...@nasa.gov>
Subject Re: allocator and using malloc alternatives
Date Wed, 19 May 2010 15:34:11 GMT
I realized last night that we're mixing up semantics a bit...

Let me pose the following (pseudo)code:

apr_allocator_create_with_alt_alloc(&allocator, alloc_fn, free_fn, opaque); // I realized
that the allocators should be part of the constructor for the apr_allocator_t type
apr_pool_create_ex(&pool, NULL, NULL, allocator); // standard create_ex call
char *foo = apr_psprintf(pool, "hello %s", "world");
apr_pool_create_ex(&pool2, pool, NULL, NULL); // what is the semantics of this?
apr_allocator_create_with_alt_alloc(&allocator2, alloc_fn2, free_fn2, opaque2);
apr_pool_create_ex(&pool3, pool, NULL, allocator2); // ditto, what is the semantics of

I suppose it's ok to allow child pools to have alternate allocators, the parents will just
be unawares of the memory allocated by the children but that's ok?

On May 18, 2010, at 7:48 PM, Nick Kew wrote:

> On 19 May 2010, at 02:58, Chris Knight wrote:
>> Ah, makes sense. Yeah would be insane to change the malloc replacement mid-stream
so an alternate to create_with_allocator is nice.
>> But you also bring up an important question; I argue that you should only be able
to do this on a top-level pool, not on a child pool...(In other words, create_with_allocator
would not take a parent pool pointer.)
> I disagree.  You should be able to have the parent pool manage it.
> Example: you have a shm pool.  If it's top-level, what's to stop the
> shm segment disappearing from under it?  But if the shm segment
> is created on a pool, and then the shm pool is created on the
> same pool (or a child), then you ensure the right sequencing.
> Feel free to rubbish me.  It's nearly 4am here, and I can't sleep :(
> -- 
> Nick Kew

View raw message