Cannot compile on Windows 7 64 bits with Visual Studio 2013 community.

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> > With a little work (a simple enough job that I don't need to be the one to
> > do it, I think) it should be possible to change the --disable-dns-lookup
> > option to always use synchronous lookup on hostnames, so the IP-only
> > restriction is removed at the cost of a small amount of startup lag.
> 
> I think you are confusing things by thinking of it as a startup problem.

OK, the places where I made asynchronous lookups an option are on 
command line and config-file hostames.

> The pool stuff also does DNS lookups and those may happen at non-startup time.

Right, I do tend to forget about that case.

> Even if startup works, I'd like to be able to occasionally (say daily) use 
> DNS to verify that the server is still in the pool.  That's a long-term 
> project.  Something like that would also be useful to verify that a 
> (non-pool) server hadn't moved.

Noted.

> I agree that it's worth investigating using synchronous DNS.  I expect it 
> will work fine on a lightly loaded system which covers most of the systems 
> running ntpd.
> 
> On the other hand, I think we should be able to make a clean threaded 
> version.  Don't get fooled by the current code.  It's not an inherently hard 
> problem.  A good example might be useful for other projects.

Maybe.  This is me looking for complexity reductions; important part of my job.

> > Later, after I deliver replay, I'm going to do a bunch of profiling. I'm not
> > actually convinced that the async-dns code is worth its complexity cost in
> > avoided startup lag, and I mean to measure the difference over a large
> > number of runs to find out. 
> 
> I think that will be misleading on several counts.
> 
> The question is not what is the average time, but rather what is the worst 
> case.
> 
> The performance in your environment may not tell you much about my 
> environment.

You are certainly right on the first count, but I question the second.
I believe the cost of synchronous lookups is dominated by WAN latency
rather than the local system's performance, and I think those
latencies have dropped a lot in the last decade.  Instead of
theorizing I want to *look*.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>