Closed npuichigo closed 1 year ago
It looks like the OP also posted exactly this to IRLO (https://internals.rust-lang.org/t/is-it-necessary-to-refer-to-the-unified-executor-proposal-of-c-to-improve-async-in-rust/17573?u=scottmcm) so I'm going to close this issue in favour of that.
The p2300 proposal seems to be a big killer for future C++ to provide a unified view of async computation with or without coroutine opted in.
Similarily, both Rust and C++ choose to use lazy future to express an async operation. However, since the design principle of coroutine in Rust and C++ differs, there're many differences in the async model.
In p2300 proposal, C++ gives a unified view of sender/receiver and coroutine based async models. And since the coroutine scheduling is handed by
await_suspend
in C++, it's still quite easy to switch execution context in coroutines. Without coroutine:With coroutine
In Rust, async computation is driven by coroutine with await/async, and usually a top-level executor is needed to push the progress of async execution. So in
tokio
or other community async runtime, there's often a global executor registered to run the coroutine to completion. According to this video, it's hard to do this scheduling (context switch) with await in Rust.Here, I have no idea if current Rust async design have the ability to provide the flexibility like what future C++ will give us. Or maybe we have a better solution or design for this. I think the ability of easy context switch (maybe from CPU to GPU or something else) is necessary to cover HPC with async programming instead of just IO intensive tasks.
So my question is whether it's necessary to take the evolution of async computation in future C++ into account when improve async Rust further?
Thanks.