As you know by now, you need to bring your own runtime for driving and scheduling asynchronous tasks in Rust.
Runtimes come in many flavors, from the popular Embassy embedded runtime (https://github.com/embassy-rs/embassy), which centers more on general multitasking and can replace the need for a real-time operating system (RTOS) on many platforms, to Tokio (https://github.com/tokio-rs/tokio), which centers on non-blocking I/O on popular server and desktop operating systems.
All runtimes in Rust need to do at least two things: schedule and drive objects implementing Rust’s Future trait to completion. Going forward in this chapter, we’ll mostly focus on runtimes for doing non-blocking I/O on popular desktop and server operating systems such as Windows, Linux, and macOS. This is also by far the most common type of runtime most programmers will encounter in Rust.
Taking control over how tasks are scheduled is very invasive, and it’s pretty much a one-way street. If you rely on a userland scheduler to run your tasks, you cannot, at the same time, use the OS scheduler (without jumping through several hoops), since mixing them in your code will wreak havoc and might end up defeating the whole purpose of writing an asynchronous program.
The following diagram illustrates the different schedulers:
Figure 8.1 – Task scheduling in a single-threaded asynchronous system
An example of yielding to the OS scheduler is making a blocking call using the default std::net ::TcpStream or std::thread::sleep methods. Even potentially blocking calls using primitives such as Mutex provided by the standard library might yield to the OS scheduler.
That’s why you’ll often find that asynchronous programming tends to color everything it touches, and it’s tough to only run a part of your program using async/await.
The consequence is that runtimes must use a non-blocking version of the standard library. In theory, you could make one non-blocking version of the standard library that all runtimes use, and that was one of the goals of the async_std initiative (https://book.async.rs/introduction). However, having the community agree upon one way to solve this task was a tall order and one that hasn’t really come to fruition yet.
Before we start implementing our examples, we’ll discuss the overall design of a typical async runtime in Rust. Most runtimes such as Tokio, Smol, or async-std will divide their runtime into two parts.
The part that tracks events we’re waiting on and makes sure to wait on notifications from the OS in an efficient manner is often called the reactor or driver.
The part that schedules tasks and polls them to completion is called the executor.
Let’s take a high-level look at this design so that we know what we’ll be implementing in our example.