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 Tue, 18 May 2010 23:12:10 GMT
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; 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()?

On May 18, 2010, at 3:58 PM, Nick Kew wrote:

> Aaargh, just accidentally sent this to Chris instead of list.
> /me grumbles about missing Reply-To headers.
> 
>> On 18 May 2010, at 23:14, Chris Knight wrote:
>> 
>>> +/**
>>> + * Redefines the function used by this apr_allocator to allocate a block of
memory.
>>> + * @param allocator The allocator to set the memory allocation functions on
>>> + * @param alloc_fn The function for me to call when apr_allocator_alloc is called
>>> + * @param free_fn The function for me to call when apr_allocator_free is called
>>> + * @param opaque The opaque information to pass to these back-end functions
>>> + */
>>> +typedef apr_memnode_t *(apr_allocator_alloc_fn_t)(apr_size_t size, void *opaque);
>>> +typedef void(apr_allocator_free_fn_t)(apr_memnode_t *memnode, void *opaque);
>>> +APR_DECLARE(apr_status_t) apr_allocator_set_fns(apr_allocator_t *allocator,
apr_allocator_alloc_fn_t *alloc_fn, apr_allocator_free_fn_t *free_fn, void *opaque);
>> 
>> Nice little generalisation!
>> 
>> At what point do you call apr_allocator_set_fns?  I'd guess just after the pool
>> has been created, right?  Any reason not to integrate it into pool creation
>> by passing it optional allocator fns?
>> 
>> -- 
>> Nick Kew
> 


Mime
View raw message