shiny future: Barbara enjoys an async sandwich

[seanmonstar]

Rendered

[nikomatsakis]

I like this, esp. the hints about some of the ways it might be done. Thanks @seanmonstar!

[pickfire]

Looks quite interested, a more flexible block_on, probably we want to see what is the performance cost of this.

Just wondering, now the difference is that block_on is able to run within sync code.

What if the user did not create any runtime but block_on was still called? Will the code get a runtime panic instead of compile time error?

Maybe we could have a global OnceCell and GhostCell like thing (feels like global variable) which can be enforced at compile time, to determine whether a runtime is being created? Maybe it could solve the runtime not found (runtime not created), runtime within runtime (runtime on top of runtime) and runtime feature not enabled (like io feature not enabled) issues with errors at compile time?

[nikomatsakis]

What if the user did not create any runtime but block_on was still called? Will the code get a runtime panic instead of compile time error?

This is a good question to highlight. What happens in this scenario?

Perhaps also in a case where there are multiple runtimes.

[seanmonstar]

What if the user did not create any runtime but block_on was still called? Will the code get a runtime panic instead of compile time error?

I imagined that calling block_on would have been basically what the #[runtime::main] attributes do, so it would also Just Work. It would however be more expensive then if someone set it up once. It might be possible to have it check a thread-local to prevent multiple creations, I haven't decided if this is a good or bad idea though.

Perhaps also in a case where there are multiple runtimes.

Could be an interesting separate story. There would be a lot of nuance to getting the implementation and decisions of that right. The original idea was that runtimes would all use futures::executor::enter() so that if mixed, they could at least detect the mixture and yell that it's a bad idea.

[pickfire]

I imagined that calling block_on would have been basically what the #[runtime::main] attributes do, so it would also Just Work. It would however be more expensive then if someone set it up once. It might be possible to have it check a thread-local to prevent multiple creations, I haven't decided if this is a good or bad idea though.

Something like glibc runtime feature detection which is only done once and cached? See rust-lang/rust#68455 (comment)

[seanmonstar]

I wasn't certain about the title, so I listed some alternatives. Now a few days later, I still prefer the original, but I can change if desired. Otherwise, I can just nuke this part first.

[zeenix]

While a block_on in std would already go a long way here, given how often this is needed, I wonder if we could do even better and provide a method on futures, so people can just use it like .await:

    req_has_header(req).block()

In fact, if it was up to me, I'd even want it as part of the language:

    req_has_header(req).block

[seanmonstar]

The original Future trait had a wait method, which did exactly that. We chose to remove it, because it was too easy for people to reach for instead of just letting the future be chained with others (now I'd say just .await). While I want to make it more forgiving in instances when a user has to do this, I'd still want to encourage users to try not to, since it is worse than using .await.

[zeenix]

hmm.. wait can very easily be confused with await and I can see most programmers new to async, confusing them, but I see your point.

[seanmonstar]

Right, I'm referring to Future v0.1, which existed before there was async/await syntax. People would often do things like this because of how easy it was:

first_fut.and_then(|val| {
    // a few lines of whatever
    let foo = do_another_future(val).wait();
    // and other lines
})