[ntp:hackers] Asynch resolver
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
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