Runtimes, Wakers, and the Reactor-Executor Pattern

The next function is the block_on function. I’ll go through it step by step:

1. First of all, this function takes a generic argument and will block on anything that implements our Future trait with an Output type of String (remember that this is currently the only kind of Future trait we support, so we’ll just return an empty string if there is no data to return).
2. Instead of having to take mut future as an argument, we define a variable that we declare as mut in the function body. It’s just to keep the API slightly cleaner and avoid us having to make minor changes later on.
3. Next, we create a loop. We’ll loop until the top-level future we received returns Ready.

If the future returns NotReady, we write out a message letting us know that at this point we could do other things, such as processing something unrelated to the future or, more likely, polling another top-level future if our runtime supported multiple top-level futures (don’t worry – it will be explained later on).

Note that we need to pass in an Events collection to mio’s Poll::poll method, but since there is only one top-level future to run, we don’t really care which event happened; we only care that something happened and that it most likely means that data is ready (remember – we always have to account for false wakeups anyway).

That’s all the changes we need to make to the runtime module for now.

The last thing we need to do is register interest for read events after we’ve written the request to the server in our http module.

Let’s open http.rs and make some changes.

http.rs

First of all, let’s adjust our dependencies so that we pull in everything we need:

ch08/a-runtime/src/http.rs
use crate::{future::PollState,
runtime,
 Future};
use mio::{Interest, Token};
use std::io::{ErrorKind, Read, Write};

We need to add a dependency on our runtime module as well as a few types from mio.

We only need to make one more change in this file, and that’s in our Future::poll implementation, so let’s go ahead and locate that:

We made one important change here that I’ve highlighted for you. The implementation is exactly the same, with one important difference:

ch08/a-runtime/src/http.rs
impl Future for HttpGetFuture {
  type Output = String;
  fn poll(&mut self) -> PollState<Self::Output> {
    if self.stream.is_none() {
      println!(“FIRST POLL – START OPERATION”);
      self.write_request();
runtime::registry()
        .register(self.stream.as_mut().unwrap(), Token(0), Interest::READABLE)
                .unwrap();
        }
        let mut buff = vec![0u8; 4096];
        loop {
            match self.stream.as_mut().unwrap().read(&mut buff) {
                Ok(0) => {
                    let s = String::from_utf8_lossy(&self.buffer);
                    break PollState::Ready(s.to_string());
                }
                Ok(n) => {
                    self.buffer.extend(&buff[0..n]);
                    continue;
                }
                Err(e) if e.kind() == ErrorKind::WouldBlock => {
                    break PollState::NotReady;
                }
                Err(e) => panic!(“{e:?}”),
            }
        }
    }
}

On the first poll, after we’ve written the request, we register interest in READABLE events on this TcpStream. We also removed the line:
return PollState::NotReady;

By removing his line, we’ll poll TcpStream immediately, which makes sense since we don’t really want to return control to our scheduler if we get the response immediately. You wouldn’t go wrong either way here since we registered our TcpStream as an event source with our reactor and would get a wakeup in any case. These changes were the last piece we needed to get our example back up and running.

If you remember the version from Chapter 7, we got the following output:
Program starting
FIRST POLL – START OPERATION
Schedule other tasks
Schedule other tasks
Schedule other tasks
Schedule other tasks
Schedule other tasks
Schedule other tasks
Schedule other tasks
HTTP/1.1 200 OK
content-length: 11
connection: close
content-type: text/plain; charset=utf-8
date: Thu, 16 Nov xxxx xx:xx:xx GMT
HelloWorld1
FIRST POLL – START OPERATION
Schedule other tasks
Schedule other tasks
Schedule other tasks
Schedule other tasks
Schedule other tasks
HTTP/1.1 200 OK
content-length: 11
connection: close
content-type: text/plain; charset=utf-8
date: Thu, 16 Nov xxxx xx:xx:xx GMT
HelloWorld2

In our new and improved version, we get the following output if we run it with cargo run:
Program starting
FIRST POLL – START OPERATION
Schedule other tasks
HTTP/1.1 200 OK
content-length: 11
connection: close
content-type: text/plain; charset=utf-8
date: Thu, 16 Nov xxxx xx:xx:xx GMT
HelloAsyncAwait
FIRST POLL – START OPERATION
Schedule other tasks
HTTP/1.1 200 OK
content-length: 11
connection: close
content-type: text/plain; charset=utf-8
date: Thu, 16 Nov xxxx xx:xx:xx GMT
HelloAsyncAwait