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 01:58:03 GMT
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.)

On May 18, 2010, at 6:01 PM, Nick Kew wrote:

> On 19 May 2010, at 00:12, Chris Knight wrote:
> 
>> Thanks, I mostly didn't want it to be part of apr_pool_create because then you'd
have to change every instance of calling apr_pool_create;
> 
> Yes of course.  It would be a separate create function, apr_pool_create_with_allocator
> or something similar but less verbose, and certainly nearer apr_pool_create_ex.
> 
>> plus most users will not need this capability so rather not have 99% of apr_pool_create
calls with 3 NULL's at the end. Also the semantics get a little confusing in doing this at
apr_pool_create; is the apr_pool_t * allocated from the allocator_alloc_fn or via malloc()?
> 
> :-)
> 
> Surely, from the parent pool!  That's only a question in a top-level create.
> 
> -- 
> Nick Kew


Mime
View raw message