[getdns-api] async comments (0.268)

[Phillip Hallam-Baker]

On Tue, Feb 5, 2013 at 9:35 AM, Dan Winship <dan.winship at gmail.com> wrote:

> On 02/04/2013 09:31 PM, Matt Miller wrote:
> > I personally don't have an objection to such a guarantee.  Although, in
> your problem example, the very quick workaround would be:
>
> yeah, that was just the first example I came up with
>
> >>> 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. :-)
> >
> > This could probably be worded differently, but we were operating under
> the assumption that the first implementations would not be built into libc.
>  If libc were really to implement it for us, maybe it's not necessary for
> this setup function to be called...
>
> It doesn't matter where getdns() is implemented; you still need to do
> *something* to tell it what event loop you're using.


The Microsoft .NET pattern seems to me to be the way to design an async
API. First you decide what information you want to pass in and out of the
subroutine, then you apply a formula to determine what the async call
should be.


> >>> 1.5 Calling the API Synchronously (Without Events)
>
> > For those of us involved since the beginning, we were heavily biased
> toward the asynchronous model.  Some of us fought to not have the _sync_
> functions even exist (-:
>
> Eh, they're good for simple command-line things if nothing else.
>

They are exactly what you need for writing code that actually uses threads
internally. If I have a need to access data from an external service that I
don't want to block the main app, I want that to start a thread, let it
block on the DNS lookup, then block on the request to the service and
finally kick some signal to the calling routine when it is done.

Using async I/O inside a call that is already in a separate thread only
adds complexity and makes the code less efficient.

If there is nothing better for the thread to be doing then you might as
well have it blocked on I/O than have it blocked on a wait timer. At least
if it is blocked on I/O you can know why it is waiting.


The one part of DNS lookup that I think departs from this model is the fact
that it is often desirable to throw out multiple DNS queries at the same
time.


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