add new `io_uring` on linux? should be widely adopted enough since 2025

[tx0c]

here to reference a discussion from 2020 (5 years ago) and now can be a better timing for io_uring on linux? there are other crates like https://github.com/DataDog/glommio but it's io_uring linux only, want a more general and cross platform solution like polling

@jjl The problem with io_uring is that it's only available on very recent kernel versions, and it will likely take 2-3 years before it's more widely available. This means that for Linux there probably have to be two backends: one using epoll/timerfd, and one using io_uring.

Originally posted by @yorickpeterse in #7

[zeenix]

From what I've seen and heard, io_uring has not succeeded in producing the results that everyone was hoping for. In some cases, the io_uring was even observed to be worse than non-io_uring.

[zeenix]

From what I've seen and heard, io_uring has not succeeded in producing the results that everyone was hoping for. In some cases, the io_uring was even observed to be worse than non-io_uring.

Having said that, I think it would still be a worthwhile effort to try and add io_uring support and then benchmark to see if it helps (significantly enough) with performance (throughput and latency mainly).

[yorickpeterse]

It's also worth mentioning that due to the various security issues found with io_uring, it's use is disabled in many instances. This means a runtime check of some sort would be needed to detect support for io_uring, with a fallback to epoll.

[notgull]

This is something I considered back when I was more active on this project. However, it would be a project outside of polling.

The idea was to create a new crate with an API more suited to the completions model. In that crate we would use io_uring on Linux and I/O completion ports on Windows, with a fallback to polling on other platforms. Then, rewrite async-io to use that crate instead of polling.

The problem is, io_uring meshes very poorly with not just Rust's models of safety, but also its I/O. It's practically impossible to do io_uring safely with async fn read() instead of poll_read() (see here for more info). Actually tracking this in a safe way would either add a lot of overhead or significantly change the form factor of the API. In short, it's a lot of work for something that is debatably faster.

If someone else wanted to spearhead this project, go ahead. But I doubt we'll really see the results that we want.