So, let’s recap what we have at this point by continuing where we left off in the previous chapter. We have the following:

• A Future trait
• A coroutine implementation using coroutine/await syntax and a preprocessor
• A reactor based on mio::Poll
• An executor that allows us to spawn as many top-level tasks as we want and schedules the ones that are ready to run
• An HTTP client that only makes HTTP GET requests to our local delayserver instance

It’s not that bad – we might argue that our HTTP client is a little bit limited, but that’s not the focus of this book, so we can live with that. Our coroutine implementation, however, is severely limited. Let’s take a look at how we can make our coroutines slightly more useful.

The biggest downside with our current implementation is that nothing – and I mean nothing – can live across wait points. It makes sense to tackle this problem first.

Let’s start by setting up our example.

We’ll use the “library” code from d-multiple-threads example in Chapter 8 (our last version of the example), but we’ll change the main.rs file by adding a shorter and simpler example.

Let’s set up the base example that we’ll iterate on and improve in this chapter.

Setting up the base example

Note

You can find this example in this book’s GitHub repository under ch09/a-coroutines-variables.

Perform the following steps:

1. Create a folder called a-coroutines-variables.
2. Enter the folder and run cargo init.
3. Delete the default main.rs file and copy everything from the ch08/d-multiple-threads/src folder into the ch10/a-coroutines-variables/src folder.
4. Open Cargo.toml and add the dependency on mio to the dependencies section:

mio = {version = “0.8”, features = [“net”, “os-poll”]}

You should now have a folder structure that looks like this:
src
  |– runtime
       |– executor.rs
       |– reactor.rs
  |– future.rs
  |– http.rs
  |– main.rs
  |– runtime.rs

We’ll use corofy one last time to generate our boilerplate state machine for us. Copy the following into main.rs:

ch09/a-coroutines-variables/src/main.rs
mod future;
mod http;
mod runtime;
use crate::http::Http;
use future::{Future, PollState};
use runtime::Waker;
fn main() {
    let mut executor = runtime::init();
    executor.block_on(async_main());
}
coroutine fn async_main() {
    println!(“Program starting”);
    let txt = Http::get(“/600/HelloAsyncAwait”).wait;
    println!(“{txt}”);
    let txt = Http::get(“/400/HelloAsyncAwait”).wait;
    println!(“{txt}”);
}

This time, let’s take a shortcut and write our corofied file directly back to main.rs since we’ve compared the files side by side enough times at this point. Assuming you’re in the base folder, a-coroutine-variables, write the following:
corofy ./src/main.rs ./src/main.rs

The last step is to fix the fact that corofy doesn’t know about Waker. You can let the compiler guide you to where you need to make changes by writing cargo check, but to help you along the way, there are three minor changes to make (note that the line number is the one reported by re-writing the same code that we wrote previously):
64: fn poll(&mut self
, waker: &Waker
)
82: match f1.poll(
waker
)
102: match f2.poll(
waker
)

Now, check that everything is working as expected by writing cargo run.

You should see the following output (the output has been abbreviated to save a little bit of space):
Program starting
FIRST POLL – START OPERATION
main: 1 pending tasks.
Sleep until notified.
HTTP/1.1 200 OK
[==== ABBREVIATED ====]
HelloAsyncAwait
main: All tasks are finished

Note

Remember that we need delayserver running in a terminal window so that we get a response to our HTTP GET requests. See the Technical requirements section for more information.

Now that we’ve got the boilerplate out of the way, it’s time to start making the improvements we talked about.