M:N threading done right, at last?
Conversation
If this becomes performance competitive with async I/O (I have no idea if it will be), then it'd be interesting to see the effect on the Rust ecosystem. Will sync I/O become popular again? Or will everyone stick with async because we've grown accustomed to the patterns?
4
23
The main use case is completely replacing needing a thread pool for AIO hooked up to eventfd + epoll. It avoids a ton of context switches between threads, system calls, scheduling and other resource use. It's also essentially a generic system call multiplexer for I/O and events.
1
If you want to use it properly rather than just as an AIO implementation, then you probably want to build around it rather than having portable code. If you want portable code not tied to the design of the API, then you're not going to be able to take advantage of properly.
1
If you have plenty of spare CPU time + memory, you can get comparable performance as io_uring by adding more threads as needed until you're saturating NVMe performance regardless.
It's extremely helpful anywhere needing fast AIO where CPU / memory are not sitting around unused.
If you care a lot about low latency responses rather than only throughput, you can't really replicate io_uring with epoll combined with a bunch of threads for AIO. If you just want maximum throughput from a fast NVMe drive, add more threads to the AIO thread pool as needed.