[getdns-api] getdns_return_t for destroy methods

[Goyal, Neel]

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.
>
> Thoughts?

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

--Paul Hoffman