Async DNS
Key topics
The async DNS discussion sparked a lively debate about the merits of `pthread_cancel()`, a function that allows threads to be cancelled asynchronously. Commenters weighed in on its original purpose, with some arguing it was meant for interrupting long computations, not I/O operations, while others pointed out its potential pitfalls, such as unexpectedly returning errors from previously reliable APIs. A consensus emerged that `pthread_cancel()` is problematic, with some suggesting alternative approaches, like returning ECANCELED or using `pthread_kill()` with EINTR, to achieve similar functionality without the drawbacks. The discussion remains relevant as developers continue to grapple with asynchronous programming and thread management.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
58m
Peak period
26
0-6h
Avg / period
6.1
Based on 49 loaded comments
Key moments
- 01Story posted
Dec 12, 2025 at 11:52 AM EST
25 days ago
Step 01 - 02First comment
Dec 12, 2025 at 12:50 PM EST
58m after posting
Step 02 - 03Peak activity
26 comments in 0-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 15, 2025 at 11:57 PM EST
22 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
In that discussion, most of the same points as in this article were already discussed, specifically some async DNS alternatives.
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 bad idea meant that it won out.
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)
Musl has an undocumented extension that does exactly this: PTHREAD_CANCEL_MASKED passed to pthread_setcancelstate.
It's great and it should be standardized.
Musl solves this problem by inspecting the program counter in the interrupt handler and checking if it falls specifically in that range, and if so, modifying registers such that when it returns from the signal, it returns to instructions that cause ECANCELED to be returned.
Looking at some of my shipping code, there's a fair bit that triggers a runtime `assert()` if `pthread_mutex_lock()` fails, as that should never occur outside of a locking bug of my own making.
Java has that same issue.
this is not possible if you are calling third party code that you can't modify. in this case it's probably a better idea to run it on another process and use shared memory to communicate back results. this can even be done in an airtight sandboxed manner (browsers do this for example), something that can't really be done with threads
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.
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.
It's really not.
Just because some systems took something fundamentally simple and wrapped a bunch of unnecessary complexity around it does not make it hard.
At its core, it's an elegant, minimal protocol.
We have complexity like different kinds of VPNs, from network-level VPNs to app-based VPNs to MDM-managed VPNs possibly coexisting. We have on-demand VPNs that only start when a particular domain is being visited: VPN starting because of DNS. We have user-provided or admin-provided hardcoded responses in /etc/hosts. We have user-specified resolver overrides (for example the user wants to use 8.8.8.8 not ISP resolver). We have multiple sources of network-provided resolvers from RDNSS to DHCPv6 O mode.
It is non-trivial to determine which resolver to even start sending datagrams with that elegant minimal protocol.
https://github.com/hickory-dns/hickory-dns is our Git repo
Documentation for the resolver including an example: https://docs.rs/hickory-resolver/latest/hickory_resolver/ind...
[1] https://libevent.org/libevent-book/Ref9_dns.html
POSIX can specify a new version of DNS resolution.
Applications on Linux can bypass libc.
Yes, there is separate work to discern what DNS server the system is currently using: on macOS this requires a call to an undocumented function in libSystem - that both Chromium and Tailscale use!
The golang team also thought DNS clients were simple, and it led to almost ten years of difficult to debug panics in Docker, Mesos, Terraform, Mesos, Consul, Heroku, Weave and countless other services and CLI tools written in Go. (Search "cannot unmarshal DNS message" and marvel at the thousands of forum threads and GitHub issues that all bottom out at Go implementing the original DNS spec and not following later updates.)
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 need to reimplement all of of that, too. And don't forget about nsswitch on BSD/Linux/Solaris/etc; there's no generic API that would let you plug into this cleanly, so for a complete implementation there, you need to:
- Reimplement built-in modules like `hosts` (for `/etc/hosts`), `cache` (query a local `nscd` cache, etc). Fortunately nobody is using the `nis` module anymore, even if it's still technically supported.
- Parse the nsswitch.conf configuration file, including the rule syntax for defining whether to continue/return on different status codes.
- Reimplement rule-based dispatch to both the built-in modules and custom, dynamically loaded modules (like `nss_mdns` for mDNS resolution).
This all differs slightly across operating systems in terms of API, config file format, etc, too, and of course Windows has its own completely distinct mechanisms that you'd need to handle too.
Re-implementing all of this correctly, thoroughly, and* keeping it working across OS changes is extremely non-trivial.
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?
https://developer.apple.com/documentation/technotes/tn3151-c...
[0] https://valentin.gosu.se/blog/2025/02/getaddrinfo-sucks-ever...