Linux内核AIO,开放系统调用

Question

为什么Linux Kernel AIO不支持异步"开放"系统调用？因为'open'可以长时间阻止文件系统,不能吗？

Answer 1

首先,这是一个非常精细和合法的问题; downvote是不幸的,它可能推开了比我更有知识的人.

AFAICT,没有充分的理由.你设法挖掘的讨论是相关的,但根本不令人满意(这可能也是你的结论).虽然Torvald的观点在技术上是正确的,但他们明显地忽略了房间里的大象 - GUI编程 - 以及我确信的许多其他用例.

是的,网络服务器将受到网络延迟的约束.这有点可疑,它应该是不关心所有其他IO的理由,但我可以接受.
是的,许多服务器工作负载将能够使用dentry/inode缓存,但不是全部,并且总会有丢失.
是的,"购买更多内存"的论点有效.我从来没有发现它是一个很好的论据.
然后是所有其他用例.对于很多人来说,包括GUI编程,我们有时或者很多都会阻塞; 我们永远不应该阻止.如果访问模式非常随机且时间过长,那么购买更多RAM也无济于事 - 缺少与二级存储提供的容量相同的容量.

"它应该快速"的想法也是错误的; 总是考虑远程文件系统.

唯一引人注目的一点是:

简短而甜蜜:"aio_open()"基本上不应该成为一个问题.如果它是,你错误地设计了一些东西,或者你太难以单线程化所有东西(并且通过简单地称之为"AIO"而"隐藏" 确实发生的线程 - 简而言之就是骗你自己).

这里的要点正是为了避免线程,所以这句话让我感到惊讶.甚至列举其他论点这一事实告诉我,这个论点太脆弱而无法自立.

在同一个讨论中,你可以找到Mikulas Patocka的这篇文章:

您可以使用像FreeBSD和一些商业Unices那样的内核线程模拟异步IO,但是您仍然需要尽可能多的(可能是内核)线程来处理您正在服务的请求.

(......)

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

这听起来像是一个恰当的解释,虽然显然不是一个好的解释.

请记住,这是一个旧线程,从那以后发生了很多变化,因此这个答案几乎没有价值.但是,它提供了关于为什么假设aio_open在历史上不可用的见解.此外,要了解许多内核讨论(或任何项目的内部讨论)通常期望所有参与者都从一系列假设开始.因此,完全有可能我没有以正确的方式看待这个问题.

话虽如此,这一点很有趣(Stephen C. Tweedie):

啊,但即使VMS SYS $ QIO在打开,分配IO请求数据包以及将文件位置映射到磁盘块时也是同步的.只有数据IO是异步的(而且用于Linux的Ben的异步IO东西也是如此).

为什么有趣？因为它强化了许多不同系统不open异步实现(和其他调用)的概念.此外,aio_openPOSIX没有指定,我找不到解释原因的讨论.Windows似乎也忽略了这个问题.

这就好像这个概念固有的东西是错误的或困难的,除了似乎没有人为什么最终成为一个好的案例.

我的猜测是,这只是低优先级,而且一直都是.据推测,预先包含线程或打开文件的变通方法足以满足足够的用例 - 提供功能的工作永远不会被证明是合理的.

了解为什么POSIX没有定义这样的调用会很有趣.我期待"超出范围"的理由.

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