Runtimes, Wakers, and the Reactor-Executor Pattern

Before we go any further, let’s visualize how our system is currently working if we consider it with two futures created by coroutine/wait and two calls to Http::get. The loop that polls our Future trait to completion in the main function takes the role of the executor in our visualization, and as you see, we have a chain of futures consisting of:

1. Non-leaf futures created by async/await (or coroutine/wait in our example) that simply call poll on the next future until it reaches a leaf future
2. Leaf futures that poll an actual source that’s either Ready or NotReady

The following diagram shows a simplified overview of our current design:

Figure 8.2 – Executor and Future chain: current design

If we take a closer look at the future chain, we can see that when a future is polled, it polls all its child futures until it reaches a leaf future that represents something we’re actually waiting on. If that future returns NotReady, it will propagate that up the chain immediately. However, if it returns Ready, the state machine will advance all the way until the next time a future returns NotReady. The top-level future will not resolve until all child futures have returned Ready.

The next diagram takes a closer look at the future chain and gives a simplified overview of how it works:

Figure 8.3 – Future chain: a detailed view

The first improvement we’ll make is to avoid the need for continuous polling of our top-level future to drive it forward.

We’ll change our design so that it looks more like this:

Figure 8.4 – Executor and Future chain: design 2

In this design, we use the knowledge we gained in Chapter 4, but instead of simply relying on epoll, we’ll use mio’s cross-platform abstraction instead. The way it works should be well known to us by now since we already implemented a simplified version of it earlier.

Instead of continuously looping and polling our top-level future, we’ll register interest with the Poll instance, and when we get a NotReady result returned, we wait on Poll. This will put the thread to sleep, and no work will be done until the OS wakes us up again to notify us that an event we’re waiting on is ready.

This design will be much more efficient and scalable.