[Unbound-users] libunbound: nonblocking name resolution, threads, processes
psimerda at redhat.com
Fri Mar 21 09:13:20 UTC 2014
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:
The still very simple libunbound plugin:
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.
More information about the Unbound-users