block_on RFC

[yoshuawuyts]

We saw rust-lang/rust#65875 closed and requiring an RFC. The working group should probably pick this up.

[elichai]

I believe that if we can get a block_on that makes the whole async/await zero cost then this can be really amazing, and then libraries can default to async functions and you can easily convert those to blocking by calling block_on (and maybe in the future it could be part of the language, which will then remove the need for a separate async-std).

Is this even feasible?
Can this:

async fn something(inputs) -> return;

fn main() {
   block_on(something(...));
}

optimize the same as this?

fn something(input) -> return;

fn main() {
something(...);
}

Right now futures_executor::block_on is 100% not zero cost even for the simplest functions.
async: https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=42ad7fb49c98eba138816825153b37ae
regular: https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=42ad7fb49c98eba138816825153b37ae
(look at the ASM difference)

[Thomasdezeeuw]

I believe that if we can get a block_on that makes the whole async/await zero cost then this can be really amazing, and then libraries can default to async functions and you can easily convert those to blocking by calling block_on (and maybe in the future it could be part of the language, which will then remove the need for a separate async-std).

Doing something "async", e.g. non-blocking I/O, but then blocking is often more costly than doing blocking I/O. So I don't think this is possible for many operations.