Creating Your Own Runtime

In the last few chapters, we covered a lot of aspects that are relevant to asynchronous programming in Rust, but we did that by implementing alternative and simpler abstractions than what we have in Rust today.

This last chapter will focus on bridging that gap by changing our runtime so that it works with Rust futures and async/await instead of our own futures and coroutine/wait. Since we’ve pretty much covered everything there is to know about coroutines, state machines, futures, wakers, runtimes, and pinning, adapting what we have now will be a relatively easy task.

When we get everything working, we’ll do some experiments with our runtime to showcase and discuss some of the aspects that make asynchronous Rust somewhat difficult for newcomers today.

We’ll also take some time to discuss what we might expect in the future with asynchronous Rust before we summarize what we’ve done and learned in this book.

We’ll...

Technical requirements

The examples in this chapter will build on the code from the last chapter, so the requirements are the same. The example is cross-platform and will work on all platforms that Rust (https://doc.rust-lang.org/beta/rustc/platform-support.html#tier-1-with-host-tools) and mio (https://github.com/tokio-rs/mio#platforms) support.

The only thing you need is Rust installed and the book’s repository downloaded locally. All the code in this chapter can be found in the ch10 folder.

We’ll use delayserver in this example as well, so you need to open a separate terminal, enter the delayserver folder at the root of the repository, and type cargo run so it’s ready and available for the examples going forward.

Remember to change the ports in the code if for some reason you have to change what port delayserver listens on.

Creating our own runtime with futures and async/await

Okay, so we’re in the home stretch; the last thing we’ll...

Experimenting with our runtime

Note

You’ll find this example in the book’s repository in the ch10/b-rust-futures-experiments folder. The different experiments will be implemented as different versions of the async_main function numbered chronologically. I’ll indicate which function corresponds with which function in the repository example in the heading of the code snippet.

Before we start experimenting, let’s copy everything we have now to a new folder:

1. Create a new folder called b-rust-futures-experiments.
2. Copy everything from the a-rust-futures folder to the new folder.
3. Open Cargo.toml and change the name attribute to b-rust-futures-experiments.

The first experiment will be to exchange our very limited HTTP client with a proper one.

The easiest way to do that is to simply pick another production-quality HTTP client library that supports async Rust and use that instead.

So, when trying to find a suitable replacement for...

Challenges with asynchronous Rust

So, while we’ve seen with our own eyes that the executor and reactor could be loosely coupled, which in turn means that you could in theory mix and match reactors and executors, the question is why do we encounter so much friction when trying to do just that?

Most programmers that have used async Rust have experienced problems caused by incompatible async libraries, and we saw an example of the kind of error message you would get previously.

To understand this, we have to dive a little bit deeper into the existing async runtimes in Rust, specifically those we typically use for desktop and server applications.

Explicit versus implicit reactor instantiation

Info

The type of future we’ll talk about going forward is leaf futures, the kind that actually represents an I/O operation (for example, HttpGetFuture).

When you create a runtime in Rust, you also need to create non-blocking primitives of the Rust standard library....

The future of asynchronous Rust

Some of the things that make async Rust different from other languages are unavoidable. Asynchronous Rust is very efficient, has low latency, and is backed by a very strong type system due to how the language is designed and its core values.

However, much of the perceived complexity today has more to do with the ecosystem and the kind of issues that result from a lot of programmers having to agree on the best way to solve different problems without any formal structure. The ecosystem gets fragmented for a while, and together with the fact that asynchronous programming is a topic that’s difficult for a lot of programmers, it ends up adding to the cognitive load associated with asynchronous Rust.

All the issues and pain points I’ve mentioned in this chapter are constantly getting better. Some points that would have been on this list a few years ago are not even worth mentioning today.

More and more common traits and abstractions...

Summary

So, in this chapter, we did two things. First, we made some rather minor changes to our runtime so it works as an actual runtime for Rust futures. We tested the runtime using two external HTTP client libraries to learn a thing or two about reactors, runtimes, and async libraries in Rust.

The next thing we did was to discuss some of the things that make asynchronous Rust difficult for many programmers coming from other languages. In the end, we also talked about what to expect going forward.

Depending on how you’ve followed along and how much you’ve experimented with the examples we created along the way, it’s up to you what project to take on yourself if you want to learn more.

There is an important aspect of learning that only happens when you experiment on your own. Pick everything apart, see what breaks, and how to fix it. Improve the simple runtime we created to learn new stuff.

There are enough interesting projects to pick from, but here...

Epilogue

So, you have reached the end. First of all, congratulations! You’ve come to the end of quite a journey!

We started by talking about concurrency and parallelism in Chapter 1. We even covered a bit about the history, CPUs and OSs, hardware, and interrupts. In Chapter 2, we discussed how programming languages modeled asynchronous program flow. We introduced coroutines and how stackful and stackless coroutines differ. We discussed OS threads, fibers/green threads, and callbacks and their pros and cons.

Then, in Chapter 3, we took a look at OS-backed event queues such as epoll, kqueue, and IOCP. We even took quite a deep dive into syscalls and cross-platform abstractions.

In Chapter 4, we hit some quite difficult terrain when implementing our own mio-like event queue using epoll. We even had to learn about the difference between edge-triggered and level-triggered events.

If Chapter 4 was somewhat rough terrain, Chapter 5 was more like climbing Mount Everest....