[getdns-api] user defined allocators

[Wiley, Glen]

Willem, Well written. Would there really be a need for "custom" helpers for non-trivial data types?  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.

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.

--
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/20130920/5538bdb6/attachment.html>