Posix AIO 坏/坏了？ [关闭]答案

【问题标题】：Posix AIO Bad/Broken? [closed]Posix AIO 坏/坏了？ [关闭]
【发布时间】：2011-03-12 10:08:49
【问题描述】：

我正在研究一个 TFTP 实现，它正在从一个复杂的多线程实现过渡到一个使用状态机来跟踪连接的会话状态的单线程/单进程实现。 TFTP 足够简单，并发会话的数量也足够少，除了大量节省代码大小和复杂性之外，对软件实际上没有任何影响。

当然，当其他人连接时，我不能只阻止单个会话。为了解决这个问题，我的第一个想法是 POSIX AIO，尽管经过一些研究我读到它是

此链接 (http://davmac.org/davpage/linux/async-io.html) 中包含一个示例，尽管我也找到了其他示例。 08 年之前的 stackoverflow 帖子 (What is the status of POSIX asynchronous I/O (AIO)?) 中给出了一些额外的观点。

对于 C 开发人员，AIO 是否仍然像人们声称的那样糟糕？人们真的不使用 AIO，而是主要坚持轮询/选择或有限大小的线程池吗？

【问题讨论】：

【解决方案1】：

记录不充分当然是这样。

大多数人确实坚持使用poll() / select()，仅仅是因为这些内容易于理解、经过充分测试、文档齐全且得到充分支持。如果我是你，我会使用 select()，除非你有令人信服的理由不这样做。

【讨论】：

【解决方案2】：

您可以考虑将Boost.Asio 用于跨平台异步套接字库。它有很好的例子，并被广泛记录。

【讨论】：

谢谢，但不幸的是，软件本身是用 C 语言编写的，可能不会改变（它将被认证，D 级航空电子软件 - 我的公司编码标准要求使用 C）。我想我使用“C/C++”引用有点粗心。
@Robert 太糟糕了。然后，您可能想删除问题中的 c++ 标志。

【解决方案3】：

我无法回答您关于 POSIX AIO 的问题，但我已将 libev 用于事件。小，快，简单。为 IO 提供了一个很好的包装器来代替 poll/select。

【讨论】：

【解决方案4】：

aio 的问题取决于平台，因此您决定的很大一部分是您的目标平台。质量差异很大，在某些情况下，它是根据轮询/选择类型调用来实现的。

在 Unix 平台上，人们确实倾向于使用 poll/select 或类似的接口，如 kevent/kqueue 或 epoll。

aio 接口存在问题，像 aio_waitcomplete() 这样的添加以及 aio 和 kqueues 的集成会有所不同。

大量线程来处理大量 I/O 并不是一个好方法。

【讨论】：

【解决方案5】：

对于磁盘，为什么必须使用 AIO 而不仅仅是缓冲读/写，除非您想 1）使用自己的缓存 2）控制对脏页的影响或 3）使用 IO 优先级？

因为如果您的目标只是代码重构，那么您可能会在当前版本中通过缓存。从缓冲 IO 更改为直接 IO 是一个巨大的变化。

例如，在具有 1.5G RAM 的 ext3/SSD/noop 上，仅 3 个线程执行 300Mb 的流式写入会导致小型写入和读取不足。将违规者切换为直接 IO 可以解决此问题，但现在写入需要永远。

【讨论】：