Errata

"runs until it is interrupted or it is yielded by the CPU voluntarily"

The paragraph is attempting to talk about nuances in CPU design, but I don't understand how the statement above relates. An interrupt can cause a context switch to the operating system that can then schedule other work on the CPU, but I'm not sure what it means for a CPU to voluntarily yield. Is this trying to say that the thread returned with the calculated result?

"If we were to use Tokio to join four Fibonacci computations we would not get an increase in speed as we are only using one thread."

This is misleading. If used similar to the Tokio reqwest example a multi-threaded runtime will be instantiated. Note the default behavior of the Tokio main macro is multi-threaded. The code sample below consumes 400% CPU. It would be more accurate to say "using one thread per task".

The point the author is trying to convey is that asynchrony does not speed up cpu-bound workloads. The following sentence gets back on track by describing that the work for one instance of the fibonacci calculation would need to be distributed across multiple cores.

#[tokio::main]
async fn main() {
let mut threads = Vec::new();

for i in 0..4 {
let handle = tokio::spawn(async move {
let result = fibonacci(4000);
println!("Thread {} result: {}", i, result);
});
threads.push(handle);
}
for handle in threads {
handle.await.unwrap();
}
}

fn fibonacci(n: u64) -> u64 {
if n == 0 || n == 1 {
return n;
}
fibonacci(n - 1) + fibonacci(n - 2)
}

"A process is a program or application that is executed by the CPU."

A process is an abstraction provided by an operating system. It would be more correct to say it is executed by the operating system on a CPU. For a book focusing on asynchronous programming it seems like it would be important to clearly describe how the application makes use of OS-provided abstractions and functionality.

In the embedded space where applications run on bare metal asynchrony makes use of hardware interrupts but none of the context in this chapter suggests that's what's being discussed.

in the example 'SelfReferential'.
"If you try and run the code, you will get a segmentation fault. The segmentation fault is an error caused by accessing memory that does not belong to the program." which is true because it's accessing the "freed" stack memory of SelfReferential::new() after it has returned, the error has no relationships with the ptr::swap operation.

correct the example by moving the self_pointer manipulation on main()'s stack and then do the swap + print is more clear.