Re: DNS cleanup
Hal Murray : > e...@thyrsus.com said: > > Be aware that at some point I would still be interested in replacing our > > internal async-lookup code with calls to c_ares or equivalent, on the > > general principle that it's better when specialty code unrelated to our > > business logic is somebody else's maintainance problem. > > One possible reason to use something else is to get the TTL from the > response. There is no way to get that with the normal API. Pardon my ignorance, but what would we use the TTL for? > Other than that, I'll be real surprised if you want to drag in another > dependency. Don't think of it as a dependency, think of it as making specialized code that we don't want to maintain into somebody else's problem. :-) > I think you said that c_ares uses a callback. To fit that into the > current/new structure, all we have to do is have the called-back routine save > or copy the data, then send a signal to the main thread. The main thread > will then call in to do the real callbacks in the right context. Noted. -- http://www.catb.org/~esr/";>Eric S. Raymond Please consider contributing to my Patreon page at https://www.patreon.com/esr so I can keep the invisible wheels of the Internet turning. Give generously - the civilization you save might be your own. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: DNS cleanup
> Pardon my ignorance, but what would we use the TTL for? It tells you when to retry the pool DNS so you will get new data. >From dig: ;; ANSWER SECTION: 0.fedora.pool.ntp.org. 150 IN A 74.82.59.150 0.fedora.pool.ntp.org. 150 IN A 104.131.53.252 0.fedora.pool.ntp.org. 150 IN A 45.127.112.2 0.fedora.pool.ntp.org. 150 IN A 208.53.158.34 The 150 is the TTL. Of course, a caching DNS server might drop them sooner. Then an earlier reload might get a different answer, but if all goes well, that's a good and polite time to wait. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
TEST fails on NetBSD
Sorry about that, I didn't test the change well enough. Without this patch the warning flag added to the list needs to also be added down where the other conditional warning flags are added to CFLAGS. >Gary E. Miller gem at rellim.com >Tue Apr 11 21:05:49 UTC 2017 > >Previous message (by thread): TEST fails on NetBSD >Next message (by thread): TEST fails on NetBSD >Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] > >Yo Eric! > >It was the Trevor one. Not sure why our commit id's differ?? > >On Tue, 11 Apr 2017 17:03:32 -0400 >"Eric S. Raymond" wrote: > >> Gary E. Miller : >> > Yo Hal! >> > >> > The last commit I can build is >> > 1b47ed72aedcc8f2e39ae198a0ea26a565ca6a15 and that one works for me. >> > >> > Whoever broke head this morning, please fix it. >> >> There ain't much there there. >> >> commit 8b13059e4936e7424062f0b69737b3ecbd96317e >> Author: Eric S. Raymond >> Date: Tue Apr 11 15:41:32 2017 -0400 >> >> Revert "easier-to-use conditional warning flags" >> >> It broke the configure logic. >> ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
