Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Async DNS

flak.tedunangst.com

Post reply on HN
Print view View original

31–40 of 50 posts

Re: Async DNS

#31

Post by frumplestlatz »

dweekly wrote: post #30
frumplestlatz wrote: post #25

Earlier quoted context omitted.

Even once you use the private `dns_config*()` APIs on macOS, you need to put in heavy lifting to correctly handle scoped, service-specific providers, supplemental matching rules, etc -- none of which is documented, and can change in the future. Since you're not using the system resolver, you won't benefit from mDNSResponder's built-in DNS caching and mDNS resolution/caching/service registration, so you're going to ne…

Good points, all - there is a lot of subtlety here. CFHostStartInfoResolution is deprecated, no? https://developer.apple.com/documentation/cfnetwork/cfhostst... :) That leaves us with DNSServiceGetAddrInfo? https://developer.apple.com/documentation/dnssd/dnsservicege... :) or some kinda convoluted use of Network and NWEndpoint/NWconnection with continuations could do the same?

Oh yes, good catch. Yeah, you want to use `NWConnection` (or one of the other higher-level supported networking APIs), which raises another issue with doing custom DNS resolution. You need those API's connect-by-name semantics to get VPN-on-Demand:

https://developer.apple.com/documentation/technotes/tn3151-c...

Re: Async DNS

#33

Post by marcosdumay »

paulddraper wrote: post #12
frumplestlatz wrote: post #7

Earlier quoted context omitted.

I am always amused when folks rediscover the bad idea that is `pthread_cancel()` — it’s amazing that it was ever part of the standard. We knew it was a bad idea at the time it was standardized in the 1990s, but politics — and the inevitable allure of a very convenient sounding (but very bad) idea — meant that the bad idea won. Funny enough, while Java has deprecated their version of thread cancellation for the same r…

IO can fail at any point though, so that’s not particularly bad.

It's particularly bad because thread interruptions are funneled into the same system as IO errors, so it's easy to consume them by mistake.

Java has that same issue.

Re: Async DNS

#35

Post by cryptonector »

frumplestlatz wrote: post #7
albertzeyer wrote: post #2

The first linked article was recently discussed here: RIP pthread_cancel ( https://news.ycombinator.com/item?id=45233713 ) In that discussion, most of the same points as in this article were already discussed, specifically some async DNS alternatives. See also here the discussion: https://github.com/crystal-lang/crystal/issues/13619

I am always amused when folks rediscover the bad idea that is `pthread_cancel()` — it’s amazing that it was ever part of the standard. We knew it was a bad idea at the time it was standardized in the 1990s, but politics — and the inevitable allure of a very convenient sounding (but very bad) idea — meant that the bad idea won. Funny enough, while Java has deprecated their version of thread cancellation for the same r…

`pthread_cancel()` is necessary _only_ to interrupt compute-only code without killing the entire process. That's it. The moment you try to use it to interrupt _I/O_ you lose -- you lose BIG.

Re: Async DNS

#36

Post by cryptonector »

AndyKelley wrote: post #10
frumplestlatz wrote: post #7

Earlier quoted context omitted.

I am always amused when folks rediscover the bad idea that is `pthread_cancel()` — it’s amazing that it was ever part of the standard. We knew it was a bad idea at the time it was standardized in the 1990s, but politics — and the inevitable allure of a very convenient sounding (but very bad) idea — meant that the bad idea won. Funny enough, while Java has deprecated their version of thread cancellation for the same r…

What's crazy is that it's almost good. All they had to do was make the next syscall return ECANCELED (already a defined error code!) rather than terminating the thread. Musl has an undocumented extension that does exactly this: PTHREAD_CANCEL_MASKED passed to pthread_setcancelstate. It's great and it should be standardized.

`pthread_cancel()` was meant for interrupting long computations, not I/O.

Re: Async DNS

#37

Post by cryptonector »

gpderetta wrote: post #23
AndyKelley wrote: post #10

Earlier quoted context omitted.

What's crazy is that it's almost good. All they had to do was make the next syscall return ECANCELED (already a defined error code!) rather than terminating the thread. Musl has an undocumented extension that does exactly this: PTHREAD_CANCEL_MASKED passed to pthread_setcancelstate. It's great and it should be standardized.

You can sort of emulate that with pthread_kill and EINTR but you need to control all code that can call interruptable sys calls to correctly return without retry (or longjmp/throw from the signal handler, but then we are back in phtread_cancel territory)

In particular you need to control the signal handlers. You can't do that easily in a library.

Re: Async DNS

#38

Post by themafia »

frumplestlatz wrote: post #7
albertzeyer wrote: post #2

The first linked article was recently discussed here: RIP pthread_cancel ( https://news.ycombinator.com/item?id=45233713 ) In that discussion, most of the same points as in this article were already discussed, specifically some async DNS alternatives. See also here the discussion: https://github.com/crystal-lang/crystal/issues/13619

I am always amused when folks rediscover the bad idea that is `pthread_cancel()` — it’s amazing that it was ever part of the standard. We knew it was a bad idea at the time it was standardized in the 1990s, but politics — and the inevitable allure of a very convenient sounding (but very bad) idea — meant that the bad idea won. Funny enough, while Java has deprecated their version of thread cancellation for the same r…

It always surprised me that in the path of so many glibc functions are calls to open() items in /etc and then parse their output into some kind of value to use or possibly return.

The initialization of these objects should have been separate and then used as a parameter to the functions that operate on them. Then you could load the /etc/gai.conf configuration, parse it, then pass that to getaddrinfo(). The fact that multiple cancellation points are discreetly buried in the paths of these functions is an element of unfortunate design.

Re: Async DNS

#39

Post by Veserv »

AndyKelley wrote: post #28
gpderetta wrote: post #23

Earlier quoted context omitted.

You can sort of emulate that with pthread_kill and EINTR but you need to control all code that can call interruptable sys calls to correctly return without retry (or longjmp/throw from the signal handler, but then we are back in phtread_cancel territory)

There's a second problem here that musl also solves. If the signal is delivered in between checking for cancelation and the syscall machine code instruction, the interrupt is missed. This can cause a deadlock if the syscall was going to wait indefinitely and the application relies on cancelation for interruption. Musl solves this problem by inspecting the program counter in the interrupt handler and checking if it fa…

Introspection windows from a interrupting context are a neat technique. You can use it to implement “atomic transaction” guarantees for the interruptee as long as you control all potential interrupters. You can also implement “non-interruption” sections and bailout logic.

Re: Async DNS

#40

Post by leshow »

01HNNWZ0MV43FF wrote: post #4

It's weird to me that event-based DNS using epoll or similar doesn't have a battle-tested implementation. I know it's harder to do in C than in Rust but I'm pretty sure that's what Hickory does internally.

I use hickory a lot and have contributed to it. It does have a pretty robust async DNS implementation, and its helpfully split into multiple different crates so you can pick your entry point into the stack. For instance, it offers a recursive resolver, but you can also just import the protocol library and build your own with tokio.
Post reply on HN