首先，这是一个非常好的、合理的问题；不幸的是，它可能会赶走比我更有知识的人。
AFAICT，没有good原因。您设法挖掘的讨论是相关的，但根本不令人满意（这也可能是您的结论）。尽管 Torvald 的观点在技术上是正确的，但他们显然忽略了房间里的大象——GUI 编程——以及我确信的许多其他用例。
是的，网络服务器会受到网络延迟的限制。这应该是一个不关心所有其他 IO 的理由，这有点可疑，但我可以接受这一点。
是的，许多服务器工作负载都能够使用 dentry/inode 缓存，但不是全部，并且总会有缺失。
是的，“购买更多内存”的论点是有效的。我从来不认为这是一个好的论据。
-
然后还有所有其他用例。对于许多人来说，包括 GUI 编程，我们有时或多次阻塞并不重要；重要的是，我们可以随时阻塞。我们永远不应该阻止。如果访问模式非常随机且时间间隔很远，那么购买更多 RAM 也无济于事——缺乏与辅助存储提供的容量一样多的内存。
“无论如何都应该快”的想法也是错误的；始终考虑远程文件系统。
唯一引人注目的一点是：
简短而甜蜜：“aio_open()”基本上不应该是一个
问题。如果是，那么你设计错误了，或者你也在尝试
该死的很难单线程一切（并“隐藏”线程does只需将其称为“AIO”即可发生 - 简而言之）。
这里的重点正是为了避免线程化，所以这句话让我感到惊讶。仅列举其他论点这一事实就表明，这一论点太脆弱，无法独立存在。
在同一讨论中深入挖掘，您可以找到 Mikulas Patocka 的这篇文章：
您可以使用 FreeBSD 等内核线程来模拟异步 IO
一些商业 Unices 这样做，但你仍然需要尽可能多（可能
kernel）线程与您正在服务的请求一样多。
(...)
制作真正的异步 IO 需要重写所有文件系统
整个 VFS _from_scratch_。这不会发生。
http://lkml.iu.edu//hypermail/linux/kernel/0102.1/0074.html http://lkml.iu.edu//hypermail/linux/kernel/0102.1/0074.html
这听起来像是一个正确的解释，尽管显然不是一个好的解释。
请记住，这是一个旧线程，自那以后发生了很多变化，所以这个答案没有什么价值。然而，它提供了关于为什么假设的aio_open不可用历史地。另外，请理解许多内核讨论（或任何项目的任何内部讨论）通常期望所有参与者都从大量假设开始。因此，我完全有可能没有以正确的方式看待这个问题。
话虽如此，这一点很有趣（Stephen C. Tweedie）：
啊，但即使是 VMS SYS$QIO 也是同步进行打开、分配的
IO 请求数据包，并将文件位置映射到磁盘块。仅有的
数据 IO 始终是异步的（Ben 的 Linux 异步 IO 内容提供了
那个也是）。
http://lkml.iu.edu//hypermail/linux/kernel/0102.1/0139.html http://lkml.iu.edu//hypermail/linux/kernel/0102.1/0139.html
为什么有趣？因为它强化了这样一个观念：许多不同的系统都没有实现open（和其他调用）异步。此外，aio_openPOSIX 没有指定，我找不到解释原因的讨论。 Windows 似乎也忽略了这个问题。
就好像这个概念固有的某些东西是错误的或困难的，但似乎没有人能很好地解释为什么会这样。
我的猜测是，这只是低优先级，而且一直都是。包括预先线程化或打开文件在内的解决方法被认为足以满足足够多的用例来提供功能，但这种方法永远是不合理的。
了解为什么 POSIX 没有定义这样的调用将会很有趣。不过，我预计会有一个“超出范围”的理由。
如果你想弄清真相，我怀疑你必须将讨论带到更合适的渠道，例如 LKML。
