[ntp:hackers] Asynch resolver
David L. Mills
mills at udel.edu
Sun May 7 15:46:23 UTC 2006
It also has to be compatible with NIS.
Brian Utterback 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?
> What if the naming service is not reenterant or not idempotent? If
> handles these issues via a managed thread, is it really doing so in
> the same manner that a forked process would? 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?
> Danny Mayer wrote:
>> David L. Mills wrote:
>>> Sachin is about to tear up the resolver. We have talked about that for
>>> literally several years without a volunteer actually doing it. The goal
>>> is to be able to resolve a DNS name on-fly and update the syntax tree
>>> constructed by the parser, possibly at run time. The approach is to
>>> a process when a name pops up and terminate it when no names are
>>> left in
>>> the tree. The problem of course is how to communicate between the
>>> and forkee. Right now this is done using a temporary file, and that
>>> sucks. Various kinds of I/O pipes, etc., are also possible but equally
>> Oddly enough I just updated ntp_intres today to fix a couple of problems
>> so I have already been horrified about the way it works. That's why the
>> question of the true flag came up.
>> We have been discussing this and we concluded that what we want to do is
>> to add ISC's EventLib code into NTP and then using that makes it very
>> simple to do dns resolution directly. That way no forks would be
>> involved, there'd be no temporary files, usage of the mode 7 packets and
>> other black magic and I don't believe that it uses pipes at all. If your
>> student wants to implement it, Paul Vixie and PHK would, I'm sure, be
>> more than happy to provide advice and guidance. More than anything else
>> we need someone who has the time to spare to implement it and then
>> recode the resolution code to use it.
>>> There is precedent in using shared memory for this; at least one of the
>>> drivers does that. My question is whether this is a universal paradigm.
>>> Does it work in Windows? Is there plausible commonality over Solaris,
>>> Linux and FreeBSD? Lightwave threads have been proposed. Same
>> For Unices EventLib will do everything that is needed for all
>> supportable platforms.
>> For Windows, once there is a function that can be used to do the
>> resolution, I would just create another thread (actually it already runs
>> ntp_intres in a separate thread rather than as a separate process) and
>> it would populate the appropriate memory structures and notify the main
>> code that there is data to be picked up. It's pretty straightforward.
>> The hard part would be making sure that the locking mechanism is
>> worked out.
>>> hackers mailing list
>>> hackers at support.ntp.org
>> hackers mailing list
>> hackers at support.ntp.org
More information about the hackers