Technical requirements 257 Creating a waker in Rust can be quite a complex task since Rust wants to give us maximum flexibility on how we choose to implement wakers. The reason for this is twofold: Wakers must work just as well on a server as it does on a microcontroller A waker must be a zero-cost abstraction Realizing that most programmers never need to create their own wakers, the cost that the lack of ergonomics has was deemed acceptable. Until quite recently, the only way to construct a waker in Rust was to create something very similar to a trait object without being a trait object. To do so, you had to go through quite a complex process of constructing a v-table (a set of function pointers), combining that with a pointer to the data that the waker stored, and creating Raw Waker. Fortunately, we don't actually have to go through this process anymore as Rust now has the Wake trait. The Wake trait works if the Waker type we create is placed in Arc. Wrapping Waker in an Arc results in a heap allocation, but for most Waker implementations on the kind of systems we're talking about in this book, that's perfectly fine and what most production runtimes do. This simplifies things for us quite a bit. Info This is an example of Rust adopting what turns out to be best practices from the ecosystem. For a long time, a popular way to construct wakers was by implementing a trait called Arc Wake provided by the futures crate (https://github. com/rust-lang/futures-rs ). The futures crate is not a part of the language but it's in the rust-lang repository and can be viewed much like a toolbox and nursery for abstractions that might end up in the language at some point in the future. To avoid confusion by having multiple things with the same name, let's rename our concrete Waker type to My Waker : ch10/a-rust-futures/src/runtime/executor. rs #[derive(Clone)] pub struct My Waker { thread: Thread, id: usize, ready_queue: Arc<Mutex<Vec<usize>>>, }