[getdns-api] getdns_return_t for destroy methods
ngoyal at verisign.com
Sat Mar 8 08:05:50 MST 2014
The major area of concern is when destroying a context in a callback - there are a lot of edge cases and re-entrant scenarios that make this code a bit hairier than it needs to be. A return code would allow implementations to enforce that contexts can't be destroyed in the callbacks they are firing and communicate that back to the user.
From: Paul Hoffman [paul.hoffman at vpnc.org]
Sent: Saturday, March 08, 2014 5:33 AM
To: Goyal, Neel
Cc: getdns-api at vpnc.org
Subject: Re: [getdns-api] getdns_return_t for destroy methods
On Mar 6, 2014, at 4:26 PM, Goyal, Neel <ngoyal at verisign.com> wrote:
> I would like to propose that we change the signatures of the destroy routines such that they return getdns_return_t.
> • getdns_return_t getdns_context_destroy
> • getdns_return_t getdns_dict_destroy
> • getdns_return_t getdns_list_destroy
> This would especially be useful in getdns_context_destroy since implementations may decide that destroying a context within a callback is allowed or not. There are some fun edge cases we’ve been dealing with regarding this. Also, it keeps the API consistent with the other methods.
The current returns (void) were a conscious decision. The group decided that that it should be a void unless there are actual useful values returned. Given that the calls always succeed, what you would put in the return other than "good"?
More information about the getdns-api