fix: Found and fixed some spelling errors.

scrapped_chapters/5_reactor_executor.md

@@ -26,7 +26,7 @@ I'll re-iterate the most important parts here.
 
 1. **A reactor**
     - handles some kind of event queue
-    - has the responsibility of respoonding to events
+    - has the responsibility of responding to events
 2. **An executor**
     - Often has a scheduler
     - Holds a set of suspended tasks, and has the responsibility of resuming
@@ -34,30 +34,30 @@ I'll re-iterate the most important parts here.
 3. **The concept of a task**
     - A set of operations that can be stopped half way and resumed later on
 
-This kind of pattern common outside of Rust as well, but it's especially popular in Rust due to how well it alignes with the API provided by Rusts standard library. This model separates concerns between handling and scheduling tasks, and queing and responding to I/O events.
+This kind of pattern common outside of Rust as well, but it's especially popular in Rust due to how well it aligns with the API provided by Rusts standard library. This model separates concerns between handling and scheduling tasks, and queuing and responding to I/O events.
 
 ## The Reactor
 
 Since concurrency mostly makes sense when interacting with the outside world (or
 at least some peripheral), we need something to actually abstract over this
-interaction in an asynchronous way. 
+interaction in an asynchronous way.
 
 This is the `Reactors` job. Most often you'll
-see reactors in rust use a library called [Mio][mio], which provides non 
+see reactors in rust use a library called [Mio][mio], which provides non
 blocking APIs and event notification for several platforms.
 
 The reactor will typically give you something like a `TcpStream` (or any other resource) which you'll use to create an I/O request. What you get in return
-is a `Future`. 
+is a `Future`.
 
-We can call this kind of `Future` a "leaf Future`, since it's some operation 
+We can call this kind of `Future` a "leaf Future`, since it's some operation
 we'll actually wait on and that we can chain operations on which are performed
-once the leaf future is ready. 
+once the leaf future is ready.
 
 ## The Task
 
 In Rust we call an interruptible task a `Future`. Futures has a well defined interface, which means they can be used across the entire ecosystem. We can chain
 these `Futures` so that once a "leaf future" is ready we'll perform a set of
-operations. 
+operations.
 
 These operations can spawn new leaf futures themselves.
 
@@ -65,7 +65,7 @@ These operations can spawn new leaf futures themselves.
 
 The executors task is to take one or more futures and run them to completion.
 
-The first thing an `executor` does when it get's a `Future` is polling it.
+The first thing an `executor` does when it gets a `Future` is polling it.
 
 **When polled one of three things can happen:**
 

scrapped_chapters/introduction.md

@@ -9,7 +9,7 @@ In contrast to many other languages, Rust doesn't come with a large runtime. The
 * Provide zero cost abstractions \(a runtime is never zero cost\)
 * Usable in embedded scenarios
 
-Actually, at one point, Rust provided green threads for handling `async` programming, but they were dropped before Rust hit 1.0. The road after that has been a long one, but it has always revolved around the `Future`trait. 
+Actually, at one point, Rust provided green threads for handling `async` programming, but they were dropped before Rust hit 1.0. The road after that has been a long one, but it has always revolved around the `Future`trait.
 
 `Futures` in Rust comes in several versions, and that can be a source of some confusion for new users.
 
@@ -40,7 +40,7 @@ There were other issues as well, but the lack of ergonomics was one of the major
 
 #### Futures 0.3
 
-This is the current iteration over `Futures` and the one we'll use in our examples. This iteration solved a lot of the problems with 1.0, especially concerning ergonimics.
+This is the current iteration over `Futures` and the one we'll use in our examples. This iteration solved a lot of the problems with 1.0, especially concerning ergonomics.
 
 The `async/await` syntax was designed in tandem with `Futures 3.0` and provides a much more ergonomic way to work with `Futures`:
 
@@ -55,7 +55,7 @@ let value = executor.block_on(asyncfunc()).unwrap();
 println!("{}", value);
 ```
 
-Before we go on further, let's separate the topic of async programming into some topics to better understand what we'll cover in this book and what we'll not cover. 
+Before we go on further, let's separate the topic of async programming into some topics to better understand what we'll cover in this book and what we'll not cover.
 
 #### How \`Futures\` are implemented in the language