As announced on the Rust Blog a few weeks ago, the long awaited async-await syntax hit beta and is slated for release with 1.39 early November. Take a look at the Async Book for an in-depth introduction.
In eager anticipation of async-await, we’ve been using futures 0.1 crate for some time. But, we’re long overdue to finally take a look at where things are headed. The following is some loosely structured notes on the upcoming “stable” state of futures and async/await.
Foot in the Door
cargo new async and in Cargo.toml add:
[dependencies]
futures = { version = "0.3.0-alpha", package = "futures-preview" }
Here using the “mostly final” Futures 0.3 crate.
As explained in The Book there are three release channels: nightly, beta, and stable. You may have used “nightly” before to access the latest and greatest features- this is where async/await previously lived. “beta” is where a version goes before becoming the next “stable” release.
# Update all installed toolchains
rustup update
# List installed toolchains
rustup toolchain list
# Install beta toolchain
rustup install beta
There’s a few ways to use the beta/nightly channels:
# List toolchain overrides
rustup override list
# Set default toolchain for directory
rustup override set beta # or "nightly"
# Now defaults to beta toolchain
cargo build
# Explicitly build using beta/nightly toolchain
cargo +beta build # or "+nightly"
In src/main.rs:
async fn hello_world() {
println!("Hello world");
}
async fn start() {
hello_world().await
}
fn main() {
let future = start();
futures::executor::block_on(future);
}
cargo run to greet the world.
Notice how await is post-fix instead of await hello_world() as found in many other languages. The syntax was heavily debated, but the rationale boils down to improving: method chaining, co-existance with the ? operator, and precedence rules.
A contrived example with a series of calls (some of which can fail):
let answer = can_fail().await?
.some_func().await
.member_can_fail().await?
.get_answer()?;
You can’t understand async without understanding Rust’s Future trait. Perhaps the first thing to learn about Future is they’re lazy; nothing happens unless something “pumps” them- as executor::block_on does here. Contrast this with std::thread::spawn which creates a running thread. If futures are polled, does that mean Rust async programming isn’t event-driven à la epoll/kqueue? Don’t fret, a Waker can be used to signal the future is ready to be polled again.
Error-Handling
We have test code like:
while !done.load(Ordering::Relaxed) {
match block_on(ctx.receive()) {
Ok(msg) => {
let pipe = msg.get_pipe()?;
let mut response = msg.dup()?;
response.set_pipe(&pipe);
block_on(ctx.send(response))?;
}
_ => panic!(),
}
}
How we might re-write it:
let future = async {
while !done.load(Ordering::Relaxed) {
match ctx.receive().await {
Ok(msg) => {
let pipe = msg.get_pipe()?;
let mut response = msg.dup()?;
response.set_pipe(&pipe);
ctx.send(response).await?;
}
_ => panic!(),
}
}
};
block_on(future);
Unfortunately, how the ? operator works in async blocks (i.e. async {}) is not defined, and async closures (i.e. async || {}) are unstable.
If we replace ? with .unwrap() it compiles and runs.
Heterogeneous Returns
Given:
broker_pull_ctx.receive().for_each(|msg| {
if let Ok(msg) = msg {
broker_push_ctx.send(msg).then(|msg| {
// Do something with the message
future::ready(())
})
} else {
future::ready(())
}
});
Sadness:
|
144 | / if let Ok(msg) = msg {
145 | | broker_push_ctx.send(msg).then(|res| {
| | _____________________ -
146 | || res.unwrap().unwrap();
147 | || future::ready(())
148 | || })
| || ______________________ - expected because of this
149 | | } else {
150 | | future::ready(())
| | ^^^^^^^^^^^^^^^^^ expected struct `futures_util::future::then::Then`, found struct `futures_util::future::ready::Ready`
151 | | }
| | _________________ - if and else have incompatible types
|
= note: expected type `futures_util::future::then::Then<futures_channel::oneshot::Receiver<std::result::Result<(), runng::result::Error>>, futures_util::future::ready::Ready<_>, [closure@runng/tests/test_main.rs:145:52: 148:22]>`
found type `futures_util::future::ready::Ready<_>`
Basically, then()- like many Rust combinators- returns a distinct type (Then in this case).
If you reach for a trait object for type erasure via -> Box<dyn Future<Output = ()>> and wrap the returns in Box::new() you’ll run into:
error[E0277]: the trait bound `dyn core::future::future::Future<Output = ()>: std::marker::Unpin` is not satisfied
--> runng/tests/test_main.rs:155:58
|
155 | let fut = broker_pull_ctx.receive().unwrap().for_each(|msg| -> Box<dyn Future<Output = ()>> {
| ^^^^^^^^ the trait `std::marker::Unpin` is not implemented for `dyn core::future::future::Future<Output = ()>`
|
= note: required because of the requirements on the impl of `core::future::future::Future` for `std::boxed::Box<dyn core::future::future::Future<Output = ()>>`
Lo, the 1.33 feature “pinning”. Thankfully, the type-insanity that is Pin<Box<dyn Future<Output = T>>> is common enough that a future::BoxFuture<T> alias is provided:
let fut = broker_pull_ctx...for_each(|msg| -> future::BoxFuture<()> {
if let Ok(msg) = msg {
Box::pin(broker_push_ctx.send(msg).then(|_| { }))
} else {
Box::pin(future::ready(()))
}
});
block_on(fut);
Alternatively, you can multiplex the return with something like future::Either:
let fut = broker_pull_ctx...for_each(|msg| {
use futures::future::Either;
if let Ok(msg) = msg {
Either::Left(
broker_push_ctx.send(msg).then(|_| { })
)
} else {
Either::Right(future::ready(()))
}
});
block_on(fut);
This avoids the boxing allocation, but it might become a bit gnarly if there’s a large number of return types.
block_on() != .await
Our initial, exploratory implementation made heavy use of wait() found in futures 0.1. To transition to async/await it’s tempting to replace wait() with block_on():
#[test]
fn block_on_panic() -> runng::Result<()> {
let url = get_url();
let mut rep_socket = protocol::Rep0::open()?;
let mut rep_ctx = rep_socket.listen(&url)?.create_async()?;
let fut = async {
block_on(rep_ctx.receive()).unwrap();
};
block_on(fut);
Ok(())
}
cargo test block_on_panic yields:
---- tests::reqrep_tests::block_on_panic stdout ----
thread 'tests::reqrep_tests::block_on_panic' panicked at 'cannot execute `LocalPool` executor from within another executor: EnterError', src/libcore/result.rs:1165:5
Note this isn’t a compiler error, it’s a runtime panic. I haven’t looked into the details of this, but the problem stems from the nested calls to block_on(). It seems that if the inner future finishes immediately everything is fine, but not if it blocks. However, it works as expected with await:
let fut = async {
rep_ctx.receive().await.unwrap();
};
block_on(fut);
Async Traits
Try:
trait AsyncTrait {
async fn do_stuff();
}
Nope:
error[E0706]: trait fns cannot be declared `async`
--> src/main.rs:5:5
|
5 | async fn do_stuff();
| ^^^^^^^^^^^^^^^^^^^^
How about:
trait AsyncTrait {
fn do_stuff();
}
struct Type;
impl AsyncTrait for Type {
async fn do_stuff() { }
}
Nope:
error[E0706]: trait fns cannot be declared `async`
--> src/main.rs:11:5
|
11 | async fn do_stuff() { }
| ^^^^^^^^^^^^^^^^^^^^^^^
One work-around involves being explicit about the return types, and using an async block within the impl:
use futures::future::{self, BoxFuture, Future};
trait AsyncTrait {
fn boxed_trait() -> Box<dyn Future<Output = ()>>;
fn pinned_box() -> BoxFuture<'static, ()>;
}
impl<T> AsyncTrait for T {
fn boxed_trait() -> Box<dyn Future<Output = ()>> {
Box::new(async {
// .await to your heart's content
})
}
fn pinned_box() -> BoxFuture<'static, ()> {
Box::pin(async {
// .await to your heart's content
})
}
}
Top comments (3)
Nice writeup. I believe the Rust team and community drew a lot of inspiration from the C# async-await, during their planning and design stages? Good to see a lot of other programming languages incorporating this feature into their various ecosystems. Once more, we'll done Rust.
From the various threads I've read they look at a wide range of "prior art", and it was the main argument against postfix ".await"- it would be foreign to everyone.
Should have mentioned this is just the MVP to unblock the ecosystem and async-await is far from "finished". Should probably sneak that into the opening somewhere.
Cool.