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 _______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
