[ntp:hackers] Patches to reinstate rank variable and add end keyword.

Danny Mayer mayer at gis.net
Sat Aug 6 18:21:05 UTC 2005


Paul Vixie wrote:
> # >  If you need the async resolver as a prereq, is it really imminent?
> # 
> # 	I don't think so.  I'm pretty sure the ISC people have been working
> # on this issue for a while, and they still haven't come up with a complete
> # solution.  I know there are some initial implementations of asynchronous
> # resolvers, but every single one I've looked into has so far had some
> # serious limitations.
> 
> asynchrony in the resolver depends on asynchrony in the mainline which is
> inherently nonportable.  there is only one kind of portable asynchronous
> resolver, and that's one that lives under fork() or pthread_fork().  the
> old ntpd used fork() for this, and dave is willing to have that happen
> again now, and so am i.  (fork() is more portable than pthread_fork().)
> 
> "ares" is an asynchronous resolver that tries really hard to stick to a
> single file descriptor so that it can be used in any select()-based
> asynchronous mainline.  however, for various protocol safety reasons, you
> actually need more than one descriptor.  "ares" is a toy by today's standards.
> 
> if ntpd's mainline moved to a portable asynchrony platform such as isc
> eventlib, posix threads, or the X11 Toolkit, or similar, then i would put
> some sweat into making an asynchronous resolver that fit that platform.
> however, moving ntpd away from select() seems controversial and i don't
> think it's going to be allowed to happen.
> 

Paul, you are much more the expert in the Unix area here than I am, but 
I don't think that moving ntpd away from select() is at all 
controversial. Multithreading would be even better but I don't think 
that's going to happy so easily.

> so that leaves fork(), which because Microsoft WIN32 is also involved, i
> propose we implement by calling popen() and putting the resulting file
> descriptor into ntpd's select() mask. 

The Win32 version is already asynchonous. You shouldn't need to worry 
about Win32 since we are today using native Win32 threads to handle 
asynchonous requests, rather than creating a project. In any case since 
I'm on the project I will be sure to make it work.

Danny


More information about the hackers mailing list