[getdns-api] user defined allocators

[Willem Toorop]

op 20-09-13 20:26, Wiley, Glen schreef:
> Willem, Well written. Would there really be a need for "custom" 
> helpers for non-trivial data types?
Some applications might want to do this for performance enhancements.  
For example to manage thread-specific memory-regions that do not need 
the global lock that malloc has.  Or to keep track of a bunch of related 
allocations needed for a specific operation that, when the operation is 
done, may be freed together in one go.

But again, I think we should keep an initial implementation simple and I 
advocate global custom memory functions.

> I think we could use the system allocator in the library routines as a 
> default, if the user registers a new allocator then allocations would 
> be made using that allocator.
> In order to avoid silliness that might ensue if a custom allocator is 
> set after allocations are made custom allocators must be registered as 
> part of an initialization routine or prior to calling any other 
> library entry points.  We could set a flag to detect that public entry 
> points have been called and return FAIL if the user attempts to set a 
> custom allocator.

Sounds good.  Or an allocation counter that is decreased on frees. 
Custom memory functions may only be registered when the global 
allocation counter is zero.
> I think we almost have to follow this approach to avoid cases in which 
> we are creating non-trivial data types within the library routines – 
> unless we want to explicitly detect whether an allocator has been 
> registered every time we create one of the data types.
Yes, if we have that sort of protection, we have to use it internally as 
well...

But maybe we should postpone this and keep the implementation as 
straight forward as possible for the moment.  We could use macro's for 
malloc, free and realloc to be able to easily modify behaviour in the 
future.

-- 
Willem
>
> -- 
> Glen Wiley
> KK4SFV
> Sr. Engineer
> The Hive, Verisign, Inc.
>
> From: Willem Toorop <willem at nlnetlabs.nl <mailto:willem at nlnetlabs.nl>>
> Date: Friday, September 20, 2013 8:25 AM
> To: "getdns-api at vpnc.org <mailto:getdns-api at vpnc.org>" 
> <getdns-api at vpnc.org <mailto:getdns-api at vpnc.org>>
> Subject: Re: [getdns-api] user defined allocators
>
> Op 21-08-13 13:04, Wiley, Glen schreef:
>> As we are working on our implementation of the getdns API I realized 
>> that there doesn't seem to be a way for the helper functions that 
>> handle the dict and list types to get to the user defined allocator. 
>>  The allocator is specified in a context, however the signatures of 
>> the helper functions do not accept a context as an argument.  There 
>> are a few ways to address this:
>>
>>  1. Add a context as an argument to the helper functions.  This is
>>     probably the least disruptive to the rest of the API.
>>  2. Change the way a user defined allocator is defined.  It is likely
>>     that the application developer would expect to use the same
>>     allocator throughout the application so it may be enough to make
>>     an assignment outside a context as an initialization step.
>>
>> I am sure that there are other options, but I think approach #2 would 
>> be a comfortable way to handle this.
> I agree.
>
> Also the custom memory management functions that may be specified have 
> the same prototype as the standard C functions.  This restricts the 
> type of custom memory functions to ones that either do no custom 
> memory bookkeeping, or have the needed bookkeeping-journal in 
> globals.  Having global custom memory functions in a individual getdns 
> context feels as a discrepancy.  A global registration function would 
> suit better. For example, just like the one in libevent:
>
> *void*  getdns_set_mem_functions(*void*  *(*malloc_fn)(size_t sz),
>                                *void*  *(*realloc_fn)(*void*  *ptr, size_t sz),
>                                *void*  (*free_fn)(*void*  *ptr));
>
> I prefer custom memory management functions to be implementation 
> specific in the API, just like setting the event base is.  I feel 
> there are too many variables to consider to have a conclusive solution 
> that fits all.  It would also allow for implementations to match this 
> capability with the capabilities of the event base.
>
>
> -- Willem
>
>
> PS. An implementations that would allow bookkeeping memory functions, 
> could have a registration function that would look something like this:
> *void*  getdns_context_set_mem_functions(getdns_context_t*  *context*,
>                                        void*  *(*malloc_fn)(*void*  *journal, size_t sz),
>                                *         void*  *(*realloc_fn)(*void*  *journal,*void*  *ptr, size_t sz),
>                                *         void*  (*free_fn)(*void*  *journal,*void*  *ptr));
>
> Of course it would then also need custom list and dict create functions:
>
> struct getdns_list * getdns_list_create_custom(getdns_context_t*  *context*);*
> struct getdns_dict * getdns_dict_create_custom(getdns_context_t*  *context*);
>
> *

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://getdnsapi.net/pipermail/spec/attachments/20130923/39f5afc6/attachment-0001.html>