Linux的异步IO的状态？ [英] The state of Linux async IO?

问题描述

我在这里问，因为谷歌搜索线索，你在旋转木马上逛逛档案没有提示，目前的状态是什么。如果你去了谷歌，似乎异步IO曾经风靡一时，2001年至2003年，并在2006年的一些东西，如的epoll 和 libaio的被转动起来; KEVENT 出现，但似乎已经消失了，据我所知，目前仍无的好的方式来完成混合型和现成基于信令，异步发送文件 - 是，即使可能吗？ - 与单线程事件循环一切

I ask here since googling leads you on a merry trip around archives with no hint as to what the current state is. If you go by Google, it seems that async IO was all the rage in 2001 to 2003, and by 2006 some stuff like epoll and libaio was turning up; kevent appeared but seems to have disappeared, and as far as I can tell, there is still no good way to mix completion-based and ready-based signaling, async sendfile - is that even possible? - and everything else in a single-threaded event loop.

所以，请告诉我，我错了，这是一片光明！ - 并且，重要的是，使用什么样的API

So please tell me I'm wrong and it's all rosy! - and, importantly, what APIs to use.

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

How does Linux compare to FreeBSD and other operating systems in this regard?

推荐答案

AIO因此仍然是有限的，并开始使用一个真正的痛苦，但它那种工作在大多数情况下，一旦你通过它挖

AIO as such is still somewhat limited and a real pain to get started with, but it kind of works for the most part, once you've dug through it.

它有一些在我看来，严重的错误，但这些都是真正的特色。例如，在提交一定量的命令或数据时，你的提交线程将阻塞。我不记得此功能的确切理由，但我当时得到的答复是类似是的，当然，内核有其队列大小的限制，这是预期的。如果提交几千个请求，这是可以接受的......显然，必须有一个限制的地方。它可能是有意义从一个拒绝服务点，太（否则恶意程序可能会迫使内核通过发布十亿请求以运行内存不足）。但尽管如此，它的东西，你可以用现实正常的数字（一百元左右）遇到，它会打你意外的是，这也是白搭。另外，如果你只提交半打左右的请求，他们有点大（数据的一些兆字节）同样可能发生，显然是因为内核打破它们的子请求。这又种是有道理的，但看到怎么文档不告诉你，你应该想到，这都没有区别（除了需要更长的时间）是否读取500个字节或数据的50兆字节。

It has some in my opinion serious bugs, but those are really features. For example, when submitting a certain amount of commands or data, your submitting thread will block. I don't remember the exact justification for this feature, but the reply I got back then was something like "yes of course, the kernel has a limit on its queue size, that is as intended". Which is acceptable if you submit a few thousand requests... obviously there has to be a limit somewhere. It might make sense from a DoS point of view, too (otherwise a malicious program could force the kernel to run out of memory by posting a billion requests). But still, it's something that you can realistically encounter with "normal" numbers (a hundred or so) and it will strike you unexpectedly, which is no good. Plus, if you only submit half a dozen or so requests and they're a bit larger (some megabytes of data) the same may happen, apparently because the kernel breaks them up in sub-requests. Which, again, kind of makes sense, but seeing how the docs don't tell you, one should expect that it makes no difference (apart from taking longer) whether you read 500 bytes or 50 megabytes of data.

此外，还有似乎没有做着缓冲AIO，至少在我的任何Debian和Ubuntu系统的方式（尽管我见过其他人抱怨正好相反，即无缓冲写入实际上通过缓冲器去） 。从我可以在我的系统中看到，AIO是唯一真正异步的缓冲关闭，这是一种耻辱（这就是为什么我presently周围使用内存映射一个丑陋的构造和工作线程，而不是）。

Also, there seems to be no way of doing buffered AIO, at least on any of my Debian and Ubuntu systems (although I've seen other people complain about the exact opposite, i.e. unbuffered writes in fact going via the buffers). From what I can see on my systems, AIO is only really asynchronous with buffering turned off, which is a shame (it is why I am presently using an ugly construct around memory mapping and a worker thread instead).

与任何异步一个重要问题是能够epoll_wait（）就可以了，如果你是从磁盘IO分开别人做任何事情（如接收网络流量），这是非常重要的。当然有io_getevents，但它不是尽如人意/有用，因为它仅适用一个奇异的事情。

An important issue with anything asynchronous is being able to epoll_wait() on it, which is important if you are doing anything else apart from disk IO (such as receiving network traffic). Of course there is io_getevents, but it is not so desirable/useful, as it only works for one singular thing.

在最近的内核中，有一个 eventfd 的支持。乍一看，它出现无用的，因为它并不明显如何可能以任何方式帮助的。
然而，你的救援，还有就是无证功能的 io_set_eventfd 它可以让你与eventfd联想AIO，这是epoll_wait（） - 能。您可以通过头挖，了解它，但它肯定是有，它工作得很好。

In recent kernels, there is support for eventfd. At first sight, it appears useless, since it is not obvious how it may be helpful in any way. However, to your rescue, there is the undocumented function io_set_eventfd which lets you associate AIO with an eventfd, which is epoll_wait()-able. You have to dig through the headers to find out about it, but it's certainly there, and it works just fine.

这篇关于Linux的异步IO的状态？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！