[ntp:hackers] Asynch resolver
David L. Mills
mills at udel.edu
Mon May 8 14:05:26 UTC 2006
For everything we do here NIS must be supported.
I have nothing against pipedreams, just asked for advice and got heavy
duty advocacy. The temporary file was the solution adopted some twenty
years ago. It was necessary in order to hold association data prior to
resolving the IP address and mobilizing the association. The problem of
course is the forked process doesn't see the syntax tree in the heap; a
suggested remedy is shared memory, but I don't know how portable that is.
Paul Vixie wrote:
>> 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