[systemd-devel] [RFC] Initial libsystemd-asyncns commit

[Lennart Poettering]

On Thu, 12.12.13 14:09, Marcel Holtmann (marcel at holtmann.org) wrote:

> 
> Hi Lennart,
> 
> >> why do we have to spawn threads or do forks for DNS. This looks all
> >> pretty expensive. In ConnMan for example we just wrote our own async
> >> DNS using a mainloop. Works perfectly fine and is dirt cheap.
> > 
> > Well, we don't fork threads/processes for each call but reuse them.
> > 
> > What libasyncns does what your solution doesn't do is go via NSS. This
> > means /etc/hosts, nss-myhostname, nss-ldap, nss-mdns and so on just
> > work, while that all is lost when doing DNS natively.
> > 
> > I am pretty sure we should not bypass NSS for this. 
> 
> actually NSS for DNS is pretty nasty stuff. I am pretty sure we should
> bypass it and create a proper implementation. Is anybody actually
> using NIS or LDAP for domain name resolution?

Well, I am not opposed to having a different DNS implementation that is
smarter than the one in glibc (i.e. can do split hoirzon and stuff), but
I am sure that should be behind NSS, not bypassing it.

> The problem with NSS is that it still does not fix the fundamental
> problem. It is sequential and blocking. You can spawn as many threads
> as you want and it will stay sequential.

Are you suggesting that there was a global lock around NSS that
serializes all NSS requests? The getaddrinfo() RFC makes clear that the
call needs to be reentrant, this would hence be news to me?

> I fully agree with you that we need to consider /etc/hosts, the local
> hostname and also mDNS, but I get the feeling it would be more
> beneficial to just build that in. ConnMan ships a DNS proxy cache to
> actually be able to be smart and parallel. We did not bother with the
> details like /etc/hosts so far since our use cases always had an empty
> /etc/hosts with just localhost only anyway. However that is easy to
> fix.

Well, note that the API libasyncns exposes is actually abstract enough
to support a different backend instead of NSS. It is also close enough
to glibc to not be surprising. I am pretty sure that NSS should be kept
in the loop, but even if we decide that we shouldn't need that then
there's no reason to not do that behing the same API...

Lennart

-- 
Lennart Poettering, Red Hat