Linux内核AIO，开放系统调用

Question

为什么Linux内核AIO不支持异步“开放”系统调用？ 由于'open'可能会阻塞文件系统很长一段时间，可以吗？

Answer 1

首先，这是一个非常好的合法问题; downvote是不幸的，它可能会推开人们比我更知识渊博。

AFAICT，没有好的原因。你设法挖掘出来的讨论是相关的，但并不令人满意（这也许是你的结论）。尽管Torvald的观点在技术上是正确的，但他们清楚地忽略了房间中的大象 - GUI编程 - 以及其他许多用例，我敢肯定。

• 是的，网络服务器将受到网络延迟的约束。有点可疑，它应该是不关心所有其他IO的理由，但我可以接受。

• 是的，许多服务器工作负载将能够使用dentry/inode缓存，但不是全部，并且总会有错过。

• 是的，“购买更多内存”这个参数的作用。我从来没有发现它是一个很好的论据。

• 然后还有其他所有用例。对于包括GUI编程在内的很多人来说，我们有时或者很少阻止并不重要，我们永远不应该阻止。如果访问模式非常随机且时间很短，购买更多的内存也无济于事 - 它们的容量不如二级存储提供的容量。

  “反正应该快”的想法也是错误的;始终考虑远程文件系统。

唯一引人注目的一点是：

简短而亲切： “aio_open（）” 基本上都不应该是一个 问题。如果是这样，你错误地设计了一些东西，或者你也尝试了太多难以单线程的东西（和“隐藏”线程 确实发生，只需调用它“AIO”而不是 - 对自己说谎，简而言之）。

这里的要点正是为了避免穿线，所以这句话让我感到吃惊。其他论点甚至被列举的事实表明，这个论点太脆弱了，无法独立存在。

在同样的讨论挖周围，你可以找到这篇文章的林达Patocka：

您可以模拟异步IO与内核线程像FreeBSD和 一些商业Unix系统做，但你仍然需要尽可能多的（可能是 内核）线程尽可能多的请求，你正在服务。

（...）

制作真正的异步IO需要重写所有的文件系统和 整个VFS _from_scratch_。它不会发生。

http://lkml.iu.edu//hypermail/linux/kernel/0102.1/0074.html

这听起来像一个适当的解释，但显然不是一个好。

请记住，这是一个古老的线程，自那以后发生了很多变化，所以这个答案没有什么价值。然而，它提供了有关为什么假设aio_open不可用在历史上的洞察力。另外，要理解许多内核讨论（或针对任何项目的任何内部讨论）通常都希望所有参与者都从一大组假设开始。因此，我完全有可能不以正确的方式来看待这个问题。

话虽这么说，这是位有趣（斯蒂芬C.特威迪）：

啊，但即使VMS SYS $ QIO是打开同步在做的， 的IO请求数据包的分配和映射文件位置到磁盘块。只有 数据IO永远是异步的（并且Ben的异步IO对于Linux的东西也提供了 ）。

http://lkml.iu.edu//hypermail/linux/kernel/0102.1/0139.html

为什么有意思？因为它强化了许多不同系统不会异步实现open（和其他调用）的概念。此外，POSIX未指定aio_open，我无法找到解释原因的讨论。 Windows似乎也忽略了这个问题。

这似乎是错误或困难的概念固有的东西，除非没有人似乎为最后的原因做出了很好的理由。

我的猜测是这只是低优先级，而且一直是。预先包含线程或打开文件的变通办法足以满足足够的使用情况，而提供该功能的案例永远不会被证明是合理的。

了解为什么POSIX不定义这样的调用会很有趣。但我期望有一个“超出范围”的理由。

如果你想深究这一点，我怀疑你必须把讨论带到更合适的渠道，比如LKML。