我正在研究一个 TFTP 实现，它正在从一个复杂的多线程实现过渡到一个单线程/单进程实现，它使用状态机来跟踪连接的会话的状态。TFTP 足够简单，并且并发会话的数量足够小，除了大量的代码大小和复杂性节省之外，对软件实际上没有任何影响。
当然，当其他人连接时，我不能只阻止单个会话。为了解决这个问题，我的第一个想法是 POSIX AIO，尽管经过一些研究我读到它是
此链接 ( http://davmac.org/davpage/linux/async-io.html )中包含一个示例，尽管我也找到了其他示例。08年之前的 stackoverflow 帖子（ POSIX 异步 I/O (AIO) 的状态是什么？ ）中给出了一些额外的观点。
对于 C 开发人员来说，AIO 是否仍然像人们声称的那样破碎？人们真的不使用 AIO，而是主要坚持轮询/选择或有限大小的线程池吗？
记录不全的情况当然是这样。
大多数人都坚持使用poll()/ select()，仅仅是因为它们易于理解、经过充分测试、有据可查且得到充分支持。如果我是你，我会使用select()，除非你有令人信服的理由不使用。
aio 的问题取决于平台，因此您决定的很大一部分是您的目标平台。质量差异很大，在某些情况下，它是根据轮询/选择类型调用来实现的。
人们确实倾向于在 Unix 平台上使用 poll/select 或类似的接口，如 kevent/kqueue 或 epoll 来处理这类事情。
aio 接口存在问题，aio_waitcomplete() 之类的添加以及 aio 和 kqueues 的集成会有所不同。
处理大量 I/O 的大量线程不是一个好方法。
对于磁盘，为什么你必须有 AIO 而不是仅仅缓冲读/写，除非你想 1）使用你自己的缓存 2）控制对脏页的影响或 3）使用 IO 优先级？
因为如果您的目标只是代码重构，那么您可能会在当前版本中通过缓存。从缓冲 IO 更改为直接 IO 是一个巨大的变化。
例如，在具有 1.5G RAM 的 ext3/SSD/noop 上，仅 3 个线程执行 300Mb 的流式写入会导致小型写入和读取不足。将违规者切换到直接 IO 解决了这个问题，但现在写入需要永远。
您可能会考虑将Boost.Asio用于跨平台异步套接字库。它有很好的例子，并被广泛记录。
我无法回答您关于 POSIX AIO 的问题，但我已将libev用于事件。小，快，简单。为 IO 提供了一个很好的包装器来代替 poll/select。