[ntp:hackers] Asynch resolver

Paul Vixie paul at vix.com
Mon May 8 13:12:45 UTC 2006

> I think that we really need to be careful here. Does eventlib really
> provide asynchronous naming services, even if it is not DNS in use?

no.  eventlib is a framework and i/o scheduler inside which asynchrony
can be accomplished without calling select directly or creating threads.

> What if the naming service is not reenterant or not idempotent?

the naming service has to be implemented in terms of eventlib primatives.
i offered to do this for dns lookups if ntp were to be converted from its
explicit select() and signalled I/O to be an eventlib app.

> If eventlib handles these issues via a managed thread, is it really
> doing so in the same manner that a forked process would?

no.  eventlib doesn't touch threads at all.

> If we start using threads, we run into many of the same issues that
> we had with signaled I/O, namely, as all of the operations used by ntpd
> thread-safe?

if we really do have to run NIS as well, then eventlib is a non-starter
since NIS depends on Sun RPC and none of us are willing to re-implement
THAT in terms of eventlib primatives.

dave, is there some problem with combining pipe(), fork(), and
gethostbyname()?  i don't understand why we would need temporary files.

More information about the hackers mailing list