Pretend you haven’t read this section title and enjoy the fact that our previous example compiled and showed the correct result.

I think our coroutine implementation is so good now that we can look at some optimizations instead. There is one optimization in our executor in particular that I want to do immediately.

Before we get ahead of ourselves, let’s set everything up:

• Create a new folder called c-coroutines-problem and copy everything from b-coroutines-references over to it
• You can change the name of the project so that it corresponds with the folder by changing the name attribute in the package section in Cargo.toml, but it’s not something you need to do for the example to work

Tip

This example is located in this book’s GitHub repository in the ch09/c-coroutines-problem folder.

With that, everything has been set up.

Back to the optimization. You see, new insights into the workload our runtime will handle in real life indicate that most futures will return Ready on the first poll. So, in theory, we can just poll the future we receive in block_on once and it will resolve immediately most of the time.

Let’s navigate to src/runtime/executor.rs and take a look at how we can take advantage of this by adding a few lines of code.

If you navigate to our Executor::block_on function, you’ll see that the first thing we do is spawn the future before we poll it. Spawning the future means that we allocate space for it in the heap and store the pointer to its location in a HashMap variable.

Since the future will most likely return Ready on the first poll, this is unnecessary work that could be avoided. Let’s add this little optimization at the start of the block_on function to take advantage of this:
pub fn block_on<F>(&mut self, future: F)
    where
        F: Future<Output = String> + ‘static,
    {
        // ===== OPTIMIZATION, ASSUME READY
let waker = self.get_waker(usize::MAX);
        let mut future = future;
        match future.poll(&waker) {
            PollState::NotReady => (),
            PollState::Ready(_) => return,
        }
        // ===== END
        spawn(future);
        loop {
            …

Now, we simply poll the future immediately, and if the future resolves on the first poll, we return since we’re all done. This way, we only spawn the future if it’s something we need to wait on.

Yes, this assumes we never reach usize::MAX for our IDs, but let’s pretend this is only a proof of concept. Our Waker will be discarded and replaced by a new one if the future is spawned and polled again anyway, so that shouldn’t be a problem.

Let’s try to run our program and see what we get:
Program starting
FIRST POLL – START OPERATION
main: 1 pending tasks.
Sleep until notified.
FIRST POLL – START OPERATION
main: 1 pending tasks.
Sleep until notified.
/400/HelloAsyn
free(): double free detected in tcache 2
Aborted

Wait, what?!?

That doesn’t sound good! Okay, that’s probably a kernel bug in Linux, so let’s try it on Windows instead:
…
error: process didn’t exit successfully: `target\release\c-coroutines-
problem.exe` (exit code: 0xc0000374, STATUS_HEAP_CORRUPTION)

That sounds even worse!! What happened here?

Let’s take a closer look at exactly what happened with our async system when we made our small optimization.