Stackful coroutines to optimize block_on calls.

[zetanumbers]

There are some unfortunate circumstances where async context is not reachable, leaving block_on as the only way to await a future. For example some of C APIs force into such position. Another situation like this would be async cleanup inside of a drop.

My initial idea to circumvent this problem was to block_on not just our async code (async cleanup), but also to start running other pending tasks concurrently, essentially joining these two. You could describe it as if runtime async thread reentered the executor and started polling other tasks. However a chain of such block_on calls (even within entirely different tasks which happened to run on the same thread) would block the previous block_on calls from finishing. As a solution to that I propose to poll tasks on stackful coroutine and yield from them on block_on call to be able to switch to different tasks without blocking anything else.

Introduction of such feature may increase memory usage (Rust stack is around 2 MiB so it's not that much) but improve concurrency in such cases, but we could put a limit on the number of coroutines on a thread.

There is a safe implementation of stackful coroutines authored by Amanieu:

https://docs.rs/corosensei/0.1.4/corosensei

Also I would like to hear a bit about what is currently considered the best way for async cleanup. However I am one of the people working on AsyncDrop and I imagine eventually (but not soon) async drop will be fully implemented, so please do not just neglect this idea for not being the most optimal solution as async cleanup within drop will then most likely become the standard instead of the current "detach on drop" behaviour like with the tokio::task::JoinHandle.

[Darksonn]

To give you my frank opinion, we are very unlikely to do this. I don't know if there are technical reasons it won't work, but we do not have the bandwidth to take something like this on. Certainly, it's lower priority than io_uring, which we also don't really have the bandwidth for.