Futures created by async/await in Rust store this data in a slightly more efficient manner. In our example, we store every variable in a separate struct since I think it’s easier to reason about, but it also means that the more variables we need to store, the more space our coroutine will need. It will grow linearly with the number of different variables that need to be stored/restored between state changes. This could be a lot of data. For example, if we have 100 state changes that each need one distinct i64-sized variable to be stored to the next state, that would require a struct that takes up 100 * 8b = 800 bytes in memory.
Rust optimizes this by implementing coroutines as enums, where each state only holds the data it needs to restore in the next state. This way, the size of a coroutine is not dependent on the total number of variables; it’s only dependent on the size of the largest state that needs to be saved/restored. In the preceding example, the size would be reduced to 8 bytes since the largest space any single state change needed is enough to hold one i64-sized variable. The same space will be reused over and over.
The fact that this design allows for this optimization is significant and it’s an advantage that stackless coroutines have over stackful coroutines when it comes to memory efficiency.
The next thing we need to change is the new method on Coroutine0:
ch09/a-coroutines-variables/src/main.rs
impl Coroutine0 {
fn new() -> Self {
Self {
state: State0::Start,
stack: Stack0::default(),
}
}
}
The default value for stack is not relevant to us since we’ll overwrite it anyway.
The next few steps are the ones of most interest to us. In the Future implementation for Coroutine0, we’ll pretend that corofy added the following code to initialize, store, and restore the stack variables for us. Let’s take a look at what happens on the first call to poll now:
ch09/a-coroutines-variables/src/main.rs
State0::Start => {
// initialize stack (hoist variables)
self.stack.counter = Some(0);
// —- Code you actually wrote —-
println!(“Program starting”);
// ———————————
let fut1 = Box::new( http::Http::get(“/600/HelloAsyncAwait”));
self.state = State0::Wait1(fut1);
// save stack
}
Okay, so there are some important changes here that I’ve highlighted. Let’s go through them:
- The first thing we do when we’re in the Start state is add a segment at the top where we initialize our stack. One of the things we do is hoist all variable declarations for the relevant code section (in this case, before the first wait point) to the top of the function.
- In our example, we also initialize the variables to their initial value, which in this case is 0.
- We also added a comment stating that we should save the stack, but since all that happens before the first wait point is the initialization of counter, there is nothing to store here.
Let’s take a look at what happens after the first wait point:
ch09/a-coroutines-variables/src/main.rs
State0::Wait1(ref mut f1) => {
match f1.poll(waker) {
PollState::Ready(txt) => {
// Restore stack
let mut counter = self.stack.counter.take().unwrap();
// —- Code you actually wrote —-
println!(“{txt}”);
counter += 1;
// ———————————
let fut2 = Box::new( http::Http::get(“/400/HelloAsyncAwait”));
self.state = State0::Wait2(fut2);
// save stack
self.stack.counter = Some(counter);
}
PollState::NotReady => break PollState::NotReady,
}
}
Hmm, this is interesting. I’ve highlighted the changes we need to make.
The first thing we do is to restore the stack by taking ownership over the counter (take()replaces the value currently stored in self.stack.counter with None in this case) and writing it to a variable with the same name that we used in the code segment (counter). Taking ownership and placing the value back in later is not an issue in this case and it mimics the code we wrote in our coroutine/wait example.
The next change is simply the segment that takes all the code after the first wait point and pastes it in. In this case, the only change is that the counter variable is increased by 1.
Lastly, we save the stack state back so that we hold onto its updated state between the wait points.
Note
In Chapter 5, we saw how we needed to store/restore the register state in our fibers. Since Chapter 5 showed an example of a stackful coroutine implementation, we didn’t have to care about stack state at all since all the needed state was stored in the stacks we created.
Since our coroutines are stackless, we don’t store the entire call stack for each coroutine, but we do need to store/restore the parts of the stack that will be used across wait points. Stackless coroutines still need to save some information from the stack, as we’ve done here.
When we enter the State0::Wait2 state, we start the same way:
ch09/a-coroutines-variables/src/main.rs
State0::Wait2(ref mut f2) => {
match f2.poll(waker) {
PollState::Ready(txt) => {
// Restore stack
let mut counter = self.stack.counter.take().unwrap();
// —- Code you actually wrote —-
println!(“{txt}”);
counter += 1;
println!(«Received {} responses.», counter);
// ———————————
self.state = State0::Resolved;
// Save stack (all variables set to None already)
break PollState::Ready(String::new());
}
PollState::NotReady => break PollState::NotReady,
}
}
Since there are no more wait points in our program, the rest of the code goes into this segment and since we’re done with counter at this point, we can simply drop it by letting it go out of scope. If our variable held onto any resources, they would be released here as well.
With that, we’ve given our coroutines the power of saving variables across wait points. Let’s try to run it by writing cargo run.
You should see the following output (I’ve removed the parts of the output that remain unchanged):
…
HelloAsyncAwait
Received 2 responses.
main: All tasks are finished
Okay, so our program works and does what’s expected. Great!
Now, let’s take a look at an example that needs to store references across wait points since that’s an important aspect of having our coroutine/wait functions behave like “normal” functions.