Linux async IO的状态？

我在这里问,因为谷歌搜索引导你在档案馆周围愉快的旅行,没有暗示目前的状态.如果你去谷歌,似乎异步IO在2001年到2003年风靡一时,到2006年,有些东西就像epoll并且libaio正在出现; kevent似乎已经消失了,据我所知,仍然没有好的方法来混合基于完成和基于准备的信号,异步sendfile- 甚至可能吗？ - 以及单线程事件循环中的所有其他内容.

所以请告诉我,我错了,这一切都很美好! - 而且,重要的是,使用什么API.

在这方面,Linux与FreeBSD和其他操作系统相比如何？

像这样的AIO仍然受到一定的限制，并且开始时确实很痛苦，但是一旦您研究了它，它就可以工作了。

在我看来，它有一些严重的错误，但是这些确实是功能。例如，当提交一定数量的命令或数据时，您的提交线程将被阻止。我不记得此功能的确切理由，但是当时我得到的答复是：“是的，当然，内核对队列大小有限制，这是预期的”。如果您提交几千个请求，那是可以接受的……显然，某处必须有一个限制。从DoS的角度来看，这也可能是有道理的（否则，恶意程序可能会通过发布十亿个请求来迫使内核用尽内存）。但是，您仍然可以在现实中遇到“正常”数字（一百左右），这会意外地打击您，这是不好的。加，如果您仅提交六个左右的请求，并且它们的请求量更大（一些兆字节的数据），则可能会发生同样的情况，这显然是因为内核在子请求中将它们分解了。再次讲，这是有道理的，但是看到文档没有告诉您，您应该希望无论读取500字节还是50兆字节的数据都没有区别（除了花费更长的时间）。

同样，至少在我的任何Debian和Ubuntu系统上，似乎都没有办法进行缓冲的AIO（尽管我已经看到其他人抱怨完全相反的事情，即实际上是通过缓冲进行的无缓冲写入）。从我的系统上可以看到，AIO只是在关闭缓冲的情况下才真正异步，这是一个遗憾（这就是为什么我目前在内存映射和工作线程周围使用丑陋的结构）。

异步操作的一个重要问题是能够对其进行epoll_wait（），如果您要进行磁盘IO以外的其他任何操作（例如接收网络流量），则这一点很重要。当然有io_getevents，但是它不是那么理想/有用，因为它仅适用于一个单一的事物。

在最近的内核中，对eventfd的支持。乍一看，它似乎毫无用处，因为尚不清楚它如何以任何方式提供帮助。但是，为方便起见，有未公开说明的函数io_set_eventfd，该函数可让您将AIO与eventfd相关联，该事件可支持epoll_wait（）。您必须仔细研究标题才能找到它，但是它确实存在，并且工作正常。