Some are other will be other won't.

One problem with io_uring is that it's completion based I/O where you move ownership of an buffer to the kernel which then writes to it until the operation completes.

This means you might not be able to (sync) cancel an operation occurring in the background.

This makes it harder to integrate into some I/O libraries, as the previous fact conflicts with RAII patterns.

Another think making adaption harder is that the interfaces for reading/writing with io_uring are conceptually slightly different.

Because of this e.g. Tokio currently hasn't switched yet to use io_uring but still uses readiness based async I/O as far as I know. (Which doesn't mean it won't support it in the future.)

This issue might be relevant (mio is internally used by tokio for async I/O): https://github.com/tokio-rs/mio/issues/923

The glommio library from DataDog was specifically built around io_uring: https://www.datadoghq.com/blog/engineering/introducing-glomm...

There's the ringbahn[0] project, which is a couple of layers wrapping the liburing library; it seems like it's presenting itself as an orthogonal runtime to tokio. Meanwhile, looks like tokio is looking into the feasibility of using io_uring[1], though I'm not sure if it would be using ringbahn or not.

[0]: https://github.com/ringbahn

[1]: https://github.com/tokio-rs/tokio/issues/2411

Apart from tokio (which the sibling comment covers), you can use rio [1] which specifically uses io_uring, and can be used as a Future [2] so that you can use it as part of the wider Future ecosystem, with tokio or any other executor.

[1]: https://crates.io/crates/rio [2]: https://docs.rs/rio/0.9.4/rio/struct.Completion.html#impl-Fu...

Looks like it's on the roadmap: https://github.com/tokio-rs/tokio/issues/2411