[getdns-api] async comments (0.268)

[Paul Hoffman]

On Feb 5, 2013, at 8: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?)

I'll take Wil's word for it being possible (because they have done it) over yours that it isn't. :-) And I will note that I said "should try as best as possible", and Wil indicated that isn't easy.

But I'm not sure why this is a comment on why any of this means that this has to be part of libc or libresolv.

>> 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.)

Hrm. You went from (d) being "it will take a bunch of ugly #defines" to it not working at all. As you can see from the examples included in the tarball, it can actually work. It isn't pretty because the application and the API implementation have to pick the same event library, but if that happens, it works just fine.

FWIW, I started off with (b), but was convinced by application developers that it was a bad idea for a few reasons. One, it prevents the compiler from finding horrible and common mistakes in calls. Two, given that none of us are prescient, there is no way we can make a generic enough hole that would actually help developers, and we would end up slouching into (a).

Having said that, if whoever implements this only implements for one event library, and no one complains and thus the API implementer stays at just one event library, then all the hand-waving I did was all for naught. A future version of the API can eliminate it and say "this API requires foolib or things that can exactly wrap foolib".

>>> 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.

If I read you correctly, I agree. Do you think that should be part of this API? If so, please sketch out what it would take.

--Paul Hoffman