3 ms·
That is all well and true, and the vulnerabilities are getting fixed, but that is off-topic to the posted article. The article is more about the Rust io_uring
by pferde 2y ago
That is all well and true, and the vulnerabilities are getting fixed, but that is off-topic to the posted article.
The article is more about the Rust io_uring async implementation breaking assumption that Rust's async makes, in that a Future can only get modified when it's poll()-ed.
I'm guessing that assumption came from an expectation that all async runtimes live in userland, and this newfangled kernel-backed runtime does things on its own inside the kernel, thus breaking the original assumption.
- pornel 2y agoThe problem has been known from the beginning, because async I/O on Windows has the same issues as io_uring. Rust went with poll-based API and synchronous cancellation design anyway, because that fits ownership and borrowing. Making async cancellation work safely even in presence of memory leaks (destructors don't always run) and panics remains an unsolved design problem.
- simonask 2y agoI mean, it’s only a problem if your design is based on the Future having exclusive ownership of its read buffer, but io\_uring assumes a kind of shared ownership. The “obvious” solution is to encode that ownership model in the design, which implies some kind of cancellation mechanism. C and C++ programs have to do that too.