文章探讨了异步DNS查询的几种实现方式及其问题。作者分析了getaddrinfo线程调用、glibc的getaddrinfo_a以及c-ares库等方案，指出它们存在线程安全、可移植性或回调机制复杂等问题。作者更倾向于能直接控制事件循环的解决方案，而非依赖后台线程或信号机制。

异步DNS解析方案探讨

作者Ted Unangst在2025年9月25日发表文章，探讨了curl使用pthread_cancel实现异步DNS请求超时机制失败后，其他可行的替代方案。作者重点关注能提供事件控制、无需后台线程或信号机制的解决方案。

现有方案分析

1. 传统线程方案

   • 使用getaddrinfo创建多个线程处理请求，避免单线程阻塞
   • 也可采用独立进程实现
   • 适用于多数场景

2. glibc方案

   • getaddrinfo_a自动管理线程
   • 缺点：非跨平台、难以与事件循环整合

3. c-ares库

   • 提供线程和事件驱动两种模式
   • 事件系统存在回调嵌套风险（文档警告回调中需保持最小化处理）
   • 示例代码展示了复杂的回调管理和文件描述符跟踪

新兴替代方案

1. wadns/dns.c

   • 代码集成度高但缺乏清晰接口文档
   • 未提供独立的事件循环接入方式

2. OpenBSD的asr方案

   • 无线程设计，完全由调用方驱动事件
   • API设计类似read/write：立即返回结果或要求稍后重试
   • 示例代码比c-ares更简洁（减少约30%代码量）
   • 当前仅存在于OpenSMTPD代码库中

核心结论

作者高度评价asr的API设计，认为其通过明确的"完成/待重试"状态机制，比基于回调的c-ares更符合控制流透明的编程理念。这种同步风格的异步接口既保持了性能，又避免了回调地狱问题。

（注：原文中的代码示例已压缩说明，保留核心逻辑特征）

以下是评论内容的总结：

1. 相关讨论链接

   • 有评论指出类似话题已在其他平台讨论过，并提供了相关链接（评论1："The first linked article was recently discussed here"）
   • 另有评论补充了其他相关文章（评论4："Another related article"）

2. 异步DNS实现的现状

   • 有用户对缺乏成熟的事件驱动DNS实现表示疑惑（评论3："It's weird...doesn't have a battle-tested implementation"）
   • 也有开发者提到自行实现异步DNS客户端的可行性（评论7："DNS clients are simple enough to build"）

3. 现有解决方案

   • Python生态中已有Gevent等替代方案（评论6："Gevent provides a pluggable set of DNS resolvers"）
   • 有用户询问其他库的可能性（评论8："libuv? libevent?"）

4. 性能与修复问题

   • 有评论对性能优化方法表示好奇（评论2："how you approached performance bottlenecks"）
   • 另有用户直接提问系统级修复（评论5："Who can fix getaddrinfo?"）

5. 个人实践

   • 开发者分享实际使用体验（评论9："I'm digging dns.c and asr"）
   • 有成功实现案例（评论7："implement a pretty decent completely async Swift DNS resolver"）