[Unbound-users] libunbound: nonblocking name resolution, threads, processes

[Pavel Simerda]

Hi all,

I'm working on a generic nonblocking name resolution library with backends. I
recently added a DNS backend based on libunbound and it worked pretty much out
of the box.

But in the documentation for libunbound (and in the large comment at the
beginning of unbound.h I found a number of notes about threads and
processes. My library is explicitly avoiding creating threads and/or processes
except for special backends that actually need them.

The documentation seems to claim that under some circumstances, libunbound
creates a worker thread or proces, depending on the setting configurable via
ub_ctx_async(). Another DNS library, c-ares, is also supported and it never
creates any threads or processes. I'm curious why such a thing would be needed
in a nonblocking library itself hopefully using nonblocking IO.

I would expect ub_process() to perform one nonblocking step and ub_cancel() to
be a reliable way to cancel the query when still working. Is such mode of
operation possible with libunbound? Is there any reason against using it?

For more details about the library:

https://sourceware.org/git/?p=netresolve.git;a=blob;f=README;hb=HEAD

The still very simple libunbound plugin:

https://sourceware.org/git/?p=netresolve.git;a=blob;f=backends/ubdns.c;hb=HEAD

At first I sent the mail incorrectly, and I already got an answer from Wouter:

> libunbound has recently had a new unbound-event.h that you can
> - --enable at configure time, that gives your a libevent-based
> processing in-your-thread state machine interface.

Sounds great. Shouldn't it become the default way in the long term?

> have you seen getdnsapi.net

I read the getdns API specification some time ago and considered implementing as
one of the API layers in netresolve which is still a possibility. The design of
the main netresolve API is much simpler though and full extensibility is maintained
on the C API layer. I wasn't aware of an actual implementation of getdns-api.

On the other hand, projects can certainly benefit from each other, just as glibc
can benefit from netresolve. I would be happy to discuss the details.

Cheers,

Pavel