Hacker News Reader

Comment by YorickPeterse | Hacker News Reader

That particular paragraph can be phrased better so I'll adjust that. What I meant to say is that you can't handle it asynchronously like you can with sockets, i.e. polling it for readiness. This is because for file IO, reads and writes are always reported as being available, making epoll/kqueue/etc effectively useless.

View on HN

With io_uring, you don't poll a file descriptor for readiness and then attempt a non-blocking operation and hope it works. You submit a request and later get a response.

To be fair to the author, io_uring has not made its way very far into userspace libraries yet. Even if the language you use has async primitives, and it’s on paper a great fit for io_uring, there’s a slim to zero chance the underlying libraries you’re using are actually using it yet. (Unless you’ve gone out of your way to target io_uring and write your own code for it.)

Yeah, it's a huge challenge. A big part of the overhead of read(2) is that historically each read required a buffer allocated to it before you start the slow request, and the way languages implemented non-blocking I/O followed that API. io_uring avoids the problem with buffer pools, but that completely changes the I/O API that most languages have settled on.

io_uring can poll filesystem descriptors for readiness; epoll, select, etc come from the networking world, and aio, etc come from the disk world, and as a result both have their various blinkers / limitations.

And I guess I could have phrased it better when I mentioned newer Linux developments, as io_uring does a far more comprehensive job of handling not just filesystem descriptors and network descriptors, but also other types of character devices.

Reply on news.ycombinator.com