[getdns-api] async comments (0.268)

[William Chan (陈智昌)]

On Wed, Feb 6, 2013 at 1:27 PM, Dan Winship <dan.winship at gmail.com> wrote:
> On 02/05/2013 08:59 PM, Paul Hoffman wrote:
>>> getdns() implementation authors (which, in the long run really means
>>> "libc/libresolv maintainers")
>>
>> Stop right there. There is *no* assumption that this will be be part of libc or libresolv any time soon.
>
> "It is important that the implementation should try to replicate as best
> as possible the logic of a local getaddrinfo() when creating a new context."
>
> In the short term, you might be able to hardcode the behavior of
> getaddrinfo() on specific releases of specific OSes that you care about,
> but that doesn't seem like a plausible long-term solution. (None of the
> other async DNS libraries have managed to achieve this, why would getdns
> be any different?)

FWIW, Chromium's async DNS library successfully (as far as we can
tell) replicates the behavior from getaddrinfo() on Mac and Linux and
we're wrapping up Windows support (there's some trickery in detecting
dual stack support in the same way Windows does...we're working on
it).

>
>> That's exactly right: they don't want to, and can't. If there was only one async library that I had to worry about, you would be correct, but it is very clear different people want to use different async libraries. This leaves four choices:
>> a) I pick one and ignore the users of all other async libraries
>> b) I make a generic hole for those libraries and try to shoehorn every possible library's calls into that hole
>> c) I don't do async
>> d) I leave it up to the implementer, who will certainly hear from the application developers about which libraries they want supported
>> I chose (d).
>
>> It sounds like you want (b) that slouches into (a).
>
> I want exactly (b). (And I don't think (d) would actually work, at all.)
>
>>> On unixy platforms, all getdns() implementations are going to be based
>>> on sockets and timeouts, and all event loops are going to be based on
>>> poll() or something equivalent.
>>
>> Err, no. There are many more choices than that. In fact, today, I suspect that many more applications use { libevent | libev } instead of polling.
>
> I wasn't saying the applications were based on poll, I was saying the
> event loops are. Sure, libevent can use poll or epoll or kqueue or
> whatever, but those are all just variations on the theme of "let me know
> when one of these file descriptors is ready". So if there's an API that
> lets getdns tell the local event loop what fds it cares about, then that
> would let it integrate with libevent, libuv, GLib, Qt, Twisted, etc.
>
> -- Dan
>
> _______________________________________________
> getdns-api mailing list
> getdns-api at vpnc.org