[getdns-api] async comments (0.268)

[Phillip Hallam-Baker]

On Mon, Feb 4, 2013 at 10:04 AM, Dan Winship <dan.winship at gmail.com> wrote:

> Some comments from the point of view of thinking about reimplementing
> GLib's getaddrinfo()-in-threads-based resolver
> (http://developer.gnome.org/gio/stable/GResolver.html) with one based on
> getdns()...
>
>
> > The callback function might be called at any time, even before
> > getdns() has returned.
>
> Our experience in GNOME has been that this tends to lead to bugs; the
> code after the getdns() call has to deal with two possible states of
> the world (eg, the userarg data may or may not have been freed), and
> so code like:
>
>   status = getdns (context, name, GETDNS_RRTYPE_A, NULL,
>                    myuserdata, &transaction_id, mycallback);
>   myuserdata->id = transaction_id;
>
> would be wrong, but not obviously so (and it might actually work 100%
> of the time with one getdns implementation, but fail sporadically with
> others). It's not much harder for the getdns() implementation to just
> guarantee that it won't invoke the callback until after you return to
> the event loop, and then you protect the caller from that class of
> bugs.
>

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.

It does not seem to matte much either. Since the typical calling loop will
be

Start DNS Query 1
Start DNS Query 2
Start OCSP Query
<wait for all the above to complete>

What you can't have is a pattern where the callback is not invoked at all
if the query has been satisfied.




> > Each implementation of the DNS API will specify an extension function
> > that tells the DNS context which event base is being used.
>
> This seems inconvenient for everyone involved except the API
> specification author. :-)
>

+1

If it is a different async mode then it is a completely different API.


> I don't know how people expect async stuff to work on Windows, so I'm
> not sure what the API would have to look like there. It might involve
> replacing all the fd and pollfd args with HANDLEs.
>

There are two separate Windows platforms at this point. The old C++ library
is legacy at this point but it is very similar to the BSD scheme.

The C#/.NET version is much easier to work with. ANY synchronous system
call can be turned into an async call by declaring a delegate. The compiler
automatically generates a wrapper with BeginInvoke and EndInvoke methods
that spin out an asynchronous call.

So writing the async version of the library is really not a design issue.
It is already done for you.




>
>
> > 1.5 Calling the API Synchronously (Without Events)
>
> I think the getdns_sync_request() API probably makes sense the way it
> is, and would be useful to lots of people, but just for the record, the
> fact that it isn't cancellable means we wouldn't be able to use it to
> implement sync lookups in GLib. But making it cancellable would imply
> making it thread-safe too (since another thread would be the only
> place you could be cancelling from), so you probably don't want to go
> there.
>
> (And anyway, we can fake a cancellable synchronous lookup by doing an
> asynchronous lookup in a temporary event loop.)
> _______________________________________________
> getdns-api mailing list
> getdns-api at vpnc.org
>



-- 
Website: http://hallambaker.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vpnc.org/pipermail/getdns-api/attachments/20130204/5e73e694/attachment.html>