AnisseFor the final talk of the day, Alice Ryhl will talk about Completion-based IO.
This talk is about the old decisions that come haunting you much later when you can't change the API. And it's not about Pin.
Readiness-based IO is the old model, while completion-based IO is the new one. In the latter, more work is moved into the OS.
The AsyncRead and AsyncWrite are readiness-based. Even though completion-based IO could be implemented on top of it, it's a leaky abstraction.
Why would supporting completion-based model be important? Because the world is moving towards completion-based IO models (in red).
io_uring appeared in 2019, providing a more performant model.
It was soon cloned by Windows. Even WASI is moving towards this model, while being platform-agnostic.
The tokio documentation recommends against using tokio for reading a lot of files.
But this is obsolete, Alice says, becuase now in tokio, File IO will use io_uring transparently.
But completion-based IO has other advantages. It also provides Buffer pools, allowing to offload and batch more things to the OS. And it helps reducing memory consumption.
One approach to move to completion-based IOs is to use the same traits, but still have an extra copy.
Another would be to add compatibility at higher layer, for example the HTTP Framework, or in Stream<Item = Bytes>.
Continuing to use readiness-based IO is also still an option. And io_uring can also to readiness-based IO with IORING_OP_POLL_ADD.
And finally, Alice says "we have to do both" which enables gradual adoption of completion-based IO models.
지지 ᚠד (Jiji Freya Daniel), 黄法官