async-io
async-io copied to clipboard
smol-rs
io_uring support
Mostly for tech porn reasons, it's new and shiny. Apparently it's also faster. Not sure if it fits in async-io, because it works very different from epoll from what I understand by reading withoutboats blog.
I think io_uring would fit in async-io. We can keep using epoll and then only use io_uring inside AsyncRead and AsyncWrite implementations. So epoll would still be the primary mechanism for checking if a FD is readable or writable, while io_uring would be an optimization for fast reads and writes.
Getting async file reads and writes, random numbers and stdin/stdout would be cool... These things require a thread pool using epoll.
Is there still an interest in this? I feel like we could do this pretty easily now using the io_uring crate.
Would prefer to using: https://docs.rs/rustix/latest/rustix/io_uring/index.html. Benefits:
- Safe system call
- I/O Safety
Would prefer to using: https://docs.rs/rustix/latest/rustix/io_uring/index.html. Benefits:
* Safe system call * I/O Safety
I feel like the io_uring crate provides a more comprehensive API that makes it easier to not dip your hands in unions. Since io_uring deals in raw pointers anyhow, I doubt that I/O safety will matter much as well.
I tried integrating io_uring into async-io, but when it comes to the syscalls that async-io uses (for polling for reads and writes), epoll ends up being faster.
However it might be more useful for higher level crates, like async-net and async-fs (rel: https://github.com/smol-rs/async-fs/issues/24). In this case we can just call the operations themselves rather than needing to go through polling.
Of course, setting all of this up would be a lot of work I don't have time for. So unless someone sponsors me to do this, I'll wait for someone else to put in the elbow grease.
I did something similar for my grad project and came to the same conclusion. Using io_uring while trying to emulate the APIs of something as low level as async-io has no benefit.
