我在这里问，因为谷歌search导致你在一个快乐的旅行周围的档案，而不是暗示目前的状态是什么。 如果你经过谷歌，看起来asynchronousIO在2001年到2003年是风靡一时的，而到了2006年，一些像epoll和libaio这样的东西也出现了。 kevent出现了，但似乎已经消失了，而且据我所知，仍然没有好的方法来混合基于完成的和基于就绪的信号，asynchronous发送文件 – 甚至可能吗？ – 以及单线程事件循环中的所有其他内容。
所以请告诉我，我错了，这一切都是美好的！ – 重要的是，使用什么API。
Linux在这方面如何与FreeBSD和其他操作系统比较？
AIO本身还有一定的局限性，真正让人着迷，但是一旦你挖掘出来，这种方式大部分都是有用的。
在我看来有一些严重的错误，但这些都是真正的特征。 例如，提交一定数量的命令或数据时，提交线程将被阻塞。 我不记得这个特性的确切理由，但是当时我的答复是“当然是的，内核的队列大小是有限制的，就像预期的那样”。 如果你提交了几千个请求，这是可以接受的……显然，在某个地方必须有一个限制。 从DoS的角度来看，这也许是有道理的（否则恶意程序可能会通过发送10亿次请求来强制内核耗尽内存）。 但是，你仍然可以用“正常”的数字（一百个左右）真实地遇到这样的事情，这会令你意想不到，这是不对的。 另外，如果你只提交了大约6个请求，并且它们稍微大一些（几兆字节的数据），那么可能会发生同样的情况，显然是因为内核在子请求中分解了它们。 这又是一种有意义的方法，但是看到文档没有告诉你，你应该预期，不管你读500字节还是50兆字节的数据，它都没有什么区别（除了需要更长的时间）。
而且，至少在我的Debian和Ubuntu系统上，似乎没有办法做缓冲的AIO（尽管我见过其他人抱怨正好相反，即实际上通过缓冲区进行无缓冲写入）。 从我在我的系统上可以看到的，AIO只是在缓冲关闭的情况下才真正异步，这是一个耻辱（这就是为什么我现在围绕内存映射使用一个丑陋的构造，而是一个工作者线程）。
任何异步的一个重要问题是能够对其进行epoll_wait（），这对于除了磁盘IO之外的任何事情（例如接收网络流量）是非常重要的。 当然，有io_getevents，但它不是那么理想/有用，因为它只适用于一个单一的事情。
在最近的内核中，有对eventfd的支持。 乍看起来，这似乎是无用的，因为它不明显如何可能有所帮助。 但是，为了解决这个问题，还有一个没有记录的函数io_set_eventfd ，它可以让你把AIO和一个eventfd（epoll_wait（） – 能够）联系起来。 你必须挖掘头部来了解它，但它确实存在，它工作得很好。
异步磁盘IO是活着的，踢…它实际上是支持的，现在工作得相当好，但有很大的局限性（但是有足够的功能，一些主要的用户可以有用地使用它 – 例如MySQL的Innodb在最新版本中） 。
异步磁盘IO是以非阻塞方式（在单个线程中）调用磁盘IO操作并等待它们完成的能力。 这工作正常， http://lse.sourceforge.net/io/aio.html有更多的信息。
AIO为典型的应用程序（数据库服务器）做足够的工作就可以使用它。 AIO是创建大量线程进行同步IO，或在现在存在的系统调用的preadv系列中使用分散/聚集的好替代方案。
使用新的preadv调用可以做一个“购物清单”同步IO作业，内核会去，并从一个文件的不同偏移量中得到一堆页面。 只要你只有一个文件可以读取就可以了。 （注意：存在等效写入功能）。
poll，epoll等，都是做select（）的一种奇特的方法，它受限于较少的限制和可伸缩性的问题 – 它们可能无法轻松地与disc混合使用，但是在真实世界的应用程序中，通过使用线程相当平凡（一些数据库服务器倾向于在单独的线程中执行这些类型的操作）。 Poll（）很好，epoll比较好，对于大量的文件描述符。 对于少量文件描述符（或者特别是低文件描述符编号），select（）也可以。
我在Linux中学习的大部分异步I / O都是在Lighttpd源代码上工作的。 这是一个单线程的Web服务器，它处理许多同时连接，使用它认为是运行系统上可用的异步I / O机制中最好的。 看看源代码，它支持Linux，BSD和（我认为）其他一些操作系统。