[getdns-api] async comments (0.268)
Dan Winship
dan.winship
Tue Feb 12 14:10:26 CET 2013
On 02/09/2013 08:28 PM, Paul Hoffman wrote:
> So the only possible place for error is if the application
> changes userarg in the callback in a way that later code in
> main() is not expecting. But isn't that true of *any* async
> system? Assume your example was instead:
>
> status = getdns (context, name, GETDNS_RRTYPE_A, NULL,
> myuserdata, &transaction_id, mycallback);
> . . . // Some commands go here
> myuserdata->id = transaction_id;
>
> Then if the callback arrived after getdns() returned but where
> the ellipsis is, you would be hosed in exactly the same way as
> if the callback had been called before getdns() returned.
Yes, this is what Phillip Hallam-Baker and I were discussing earlier in
the thread; I was assuming that (a) getdns() would not create any
threads of its own internally, and (b) getdns() could only be called
from the same thread that its event loop was running in. So normally,
the callback would not be invoked until the caller returned control to
the event loop, unless getdns() invoked it directly before returning,
and I was suggesting "don't do that".
If (a) is wrong, then I don't understand why you need an event loop at
all, since getdns() could just be doing its work synchronously in that
case. And if (b) is wrong, then section 8 needs to be updated, since it
currently says that "a context should not be used by multiple threads",
and it seems like calling getdns() from a thread other than the one that
its event loop is running in would violate that.
-- Dan
More information about the spec
mailing list