[getdns-api] async comments (0.268)

[Dan Winship]

On 02/04/2013 11:07 AM, Phillip Hallam-Baker wrote:
>     > The callback function might be called at any time, even before
>     > getdns() has returned.

> I am not sure this is avoidable. The API call cannot control the
> scheduler. If there are 50 threads going at once there can be no
> guarantee that the parent thread will get called before the callback
> thread is called.

Hm... OK, we have different models of how this works... your
interpretation makes sense if getdns() behaves like BeginInvoke with an
AsyncCallback. But in that case there's not really an event loop
involved... if getdns() wants to just do blocking I/O in another thread
and then call the callback from that thread when it's done, it doesn't
need to know anything about how the rest of your program handles
events/asynchronicity.

I was assuming that you'd call getdns() in the thread where the event
loop was running, the event loop would then dispatch events to getdns
(in this same thread), and then eventually one of those events would
result in getdns invoking your callback (in the same thread). Section 8
says "contexts in implementations of the API will not necessarily be
thread-safe", so it seems like it would be illegal for an app to call
getdns() from any thread other than the one where the event loop was
running, and likewise it would be illegal for the event loop to call
back to getdns from any thread other than the one that getdns registered
itself in.

(When the docs talked about the callback running before getdns()
returned, I assumed it was suggesting that getdns() might invoke the
callback directly, eg, if it already had the answer cached and didn't
need to do any I/O.)

But anyway... the docs for getdns_cancel_callback() seem to agree with
your interpretation ("getdns_cancel_callback() may return immediately,
even before the callback finishes its work and returns." That definitely
implies the callback might be running in another thread.) So I guess I'm
confused about what's intended here.

-- Dan