mio

围绕 Rust Reactor 基石 mio 的架构、后端与使用边界。

• mio(七)：陷阱与常见错误

  2026年1月10日
  mio

  mio 的 7 个致命陷阱：不 drain 数据导致事件丢失、不处理 WouldBlock、忘记 deregister 导致资源泄漏、reregister 的覆盖语义、跨 Poll 使用 Source、在 poll 线程做阻塞操作、忽略 EINTR。建在 mio 之上的抽象还有 3 个额外陷阱。所有这些都源于 mio 的核心设计决策：边缘触发 + 非阻塞 + 手动管理。

• mio(六)：代码示例-TCP Echo Server

  2026年1月9日
  mio

  mio 官方提供的 TCP server 示例约 130 行，展示了手动事件循环的完整模式：Token 分发、WouldBlock 处理、edge-triggered drain、连接池管理。同样的功能用 tokio 约 15 行。这个对比不是在批评 mio——它精确地展示了 mio 的定位：它是操作系统事件通知的薄封装，不是应用框架。

• mio(五)：关键设计决策

  2026年1月8日
  mio

  mio 的每一个设计决策都是为 Rust 的 ownership 系统量身定做的。Token 替代回调是为了避免 closure 生命周期问题；强制边缘触发是为了简化 API 和提高性能；强制 non-blocking 是为了避免意外阻塞事件循环；没有全局状态是为了让 Poll 的生命周期完全由用户控制。

• mio(四)：为什么不直接用 mio

  2026年1月7日
  mio

  mio 刻意只做事件通知，不提供 timer、buffer 管理、async/await、任务调度。直接用 mio 写服务器代码就像用 epoll_wait 的 C 代码一样繁琐。tokio 在 mio 之上叠加了完整的异步运行时。这不是 mio 的缺陷——这是 Unix 哲学的 "do one thing well"。