[ntp:hackers] Asynch resolver

Brian Utterback Brian.Utterback at Sun.COM
Sun May 7 14:39:27 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? What 
if the naming service is not reenterant or not idempotent? If eventlib
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:
>> Guys,
>>
>> 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 fork
>> 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 forker
>> 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
>> sucks.
> 
> 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 questions.
>>
> 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.
> 
> Danny
> 
>> Dave
>> _______________________________________________
>> hackers mailing list
>> hackers at support.ntp.org
>> https://support.ntp.org/mailman/listinfo/hackers
>>
> 
> _______________________________________________
> hackers mailing list
> hackers at support.ntp.org
> https://support.ntp.org/mailman/listinfo/hackers



More information about the hackers mailing list