Async DNS
flak.tedunangst.com
Async DNS
1–10 of 50 posts
Re: Async DNS
#2The 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
Re: Async DNS
#3Just curious how you approached performance bottlenecks — anything surprising you discovered while testing?
Re: Async DNS
#4It'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.
Re: Async DNS
#5Another related article: https://ziglang.org/devlog/2025/#2025-10-15
Re: Async DNS
#6[deleted]
Re: Async DNS
#7The 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 reasons, Haskell still has theirs. When you’re writing code in IO, you have to be prepared for async cancellation anywhere, at any time.
This leads to common bugs in the standard library that you really wouldn’t expect from a language like Haskell; e.g. https://github.com/haskell/process/issues/183 (withCreateProcess async exception safety)
Re: Async DNS
#8It'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.
it’s a weird problem, in that (1) DNS is hard, and (2) you really need the upstream vendor to solve the problem, because correct applications want to use the system resolver.
If you don’t use the system resolver, you have to glue into the system’s configuration mechanism for resolvers somehow … which isn’t simple — for example, there’s a lot of complex logic on macOS around handling which resolver to use based on what connections, VPNs, etc, are present.
And the there’s nsswitch and other plugin systems that are meant to allow globally configured hooks plug into the name resolution path.
Re: Async DNS
#9Who can fix getaddrinfo?
Re: Async DNS
#10The 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…
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.