考虑一个受CPU约束但又具有高性能I / O要求的应用程序。
我正在将Linux文件I / O与Windows进行比较，我完全看不出epoll将如何帮助Linux程序。内核会告诉我文件描述符“可以读取”，但是我仍然必须调用阻塞read（）来获取数据，并且如果我想读取兆字节，很显然它将阻塞。
在Windows上，我可以创建带有OVERLAPPED设置的文件句柄，然后使用非阻塞I / O，并在I / O完成时得到通知，并使用该完成功能中的数据。我不需要花费应用程序级别的时钟时间来等待数据，这意味着我可以将线程数精确地调整为内核数，并获得100％的高效CPU利用率。
如果我必须在Linux上模拟异步I / O，则必须分配一定数量的线程来执行此操作，这些线程将花费一点时间来做CPU事情，并且会花费大量时间来阻塞I / O，加上与这些线程之间的消息传递会产生开销。因此，我将过度订购或未充分利用CPU内核。
我将mmap（）+ madvise（）（WILLNEED）视作“可怜的人的异步I / O”，但它仍然无法一路走到尽头，因为完成后我无法收到通知- 我有为“猜测”，如果我猜为“错误”，我将最终阻止内存访问，等待数据来自磁盘。
Linux似乎在io_submit中启动了异步I / O，并且它似乎也有一个用户空间POSIX aio实现，但是这种方式已经存在了一段时间，而且我知道没有人会为这些系统提供关键服务，高性能的应用程序。
Windows模型大致如下所示：
第1/2步通常是一件简单的事情。步骤3/4通常是使用工作线程池完成的，而不是（不一定）与发出I / O的线程相同。该模型与boost :: asio提供的模型有些相似，除了boost :: asio实际上并没有为您提供基于异步块的（磁盘）I / O。
与Linux中的epoll的不同之处在于，在第4步中，尚未发生任何I / O －将第1步提升到第4步之后，如果您确切地知道自己需要什么，则将其“倒退”。
对大量嵌入式，桌面和服务器操作系统进行了编程之后，我可以说这种异步I / O模型对于某些类型的程序来说是很自然的。它也是高吞吐量和低开销的。我认为这是Linux I / O模型在API级别上仍然存在的真正缺陷之一。
Peter Teoh间接指出的真实答案是基于io_setup（）和io_submit（）的。具体来说，由Peter指示的“ aio_”功能是基于线程的glibc用户级仿真的一部分，这不是有效的实现。真正的答案是：
io_submit(2) io_setup(2) io_cancel(2) io_destroy(2) io_getevents(2)
请注意，日期为2012-08的手册页指出，该实现尚未成熟到可以代替glibc用户空间仿真的程度：
http://man7.org/linux/man-pages/man7/aio.7.html
该实现尚未成熟到可以使用内核系统调用完全重新实现POSIX AIO实现的地步。
因此，根据我可以找到的最新内核文档，Linux尚没有成熟的基于内核的异步I / O模型。而且，如果我假设记录的模型实际上已经成熟，那么从recv（）vs read（）的角度来看，它仍然不支持部分I / O。
