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
>
|