From 2a879783271d6edd6943ca087738c011cfa91349 Mon Sep 17 00:00:00 2001 From: Cem Karan Date: Wed, 23 Dec 2020 09:48:31 -0500 Subject: [PATCH] fix: Found and fixed some spelling errors. --- README.md | 2 +- scrapped_chapters/5_reactor_executor.md | 18 +++++++++--------- scrapped_chapters/introduction.md | 6 +++--- src/1_futures_in_rust.md | 4 ++-- src/2_a_mental_model_for_futures.md | 2 +- src/6_future_example.md | 2 +- src/conclusion.md | 2 +- 7 files changed, 18 insertions(+), 18 deletions(-) diff --git a/README.md b/README.md index 6dde038..0d721f3 100644 --- a/README.md +++ b/README.md @@ -56,7 +56,7 @@ in the `Poll` method and a possible race condition. See #2 for more details. **2020-04-13:** Added a "bonus section" to the [Implementing Futures chapter](https://cfsamson.github.io/books-futures-explained/6_future_example.html) where we avoid using `thread::park` and instead show how we can use a `Condvar` and a `Mutex` to create a proper `Parker`. Updated the [Finished Example](https://cfsamson.github.io/books-futures-explained/8_finished_example.html) to reflect these changes. Unfortunately, this led us -a few lines over my initial promis of keeping the example below 200 LOC but the I think the inclusion +a few lines over my initial promise of keeping the example below 200 LOC but the I think the inclusion is worth it. **2020-12-21:** Rewrote the "Runtimes" paragraph of chapter 2 adding a useful model to understand diff --git a/scrapped_chapters/5_reactor_executor.md b/scrapped_chapters/5_reactor_executor.md index 1e537f3..1a92389 100644 --- a/scrapped_chapters/5_reactor_executor.md +++ b/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:** diff --git a/scrapped_chapters/introduction.md b/scrapped_chapters/introduction.md index ed486fa..dc03503 100644 --- a/scrapped_chapters/introduction.md +++ b/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 diff --git a/src/1_futures_in_rust.md b/src/1_futures_in_rust.md index 7467811..0167de4 100644 --- a/src/1_futures_in_rust.md +++ b/src/1_futures_in_rust.md @@ -119,8 +119,8 @@ this task. So, how does these three parts work together? They do that through an object called the `Waker`. The `Waker` is how the reactor tells the executor that a specific Future is ready to run. Once you -understand the lifecycle and ownership of a Waker, you'll understand how futures work from a user's -perspective. Here is the lifecycle: +understand the life cycle and ownership of a Waker, you'll understand how futures work from a user's +perspective. Here is the life cycle: - A Waker is created by the **executor** - When a future is registered with an executor, it’s given a clone of the Waker object created by diff --git a/src/2_a_mental_model_for_futures.md b/src/2_a_mental_model_for_futures.md index fbc1834..69cf37b 100644 --- a/src/2_a_mental_model_for_futures.md +++ b/src/2_a_mental_model_for_futures.md @@ -2,7 +2,7 @@ The main goal in this part is to build a high level mental model of how the different pieces we read about in the previous chapter -works toghether. I hope this will make it easier to understand what we just read +works together. I hope this will make it easier to understand what we just read about in the previous chapter and also explain why we take a deep dive into topics like trait objects and generators in the next few chapters. diff --git a/src/6_future_example.md b/src/6_future_example.md index 5bb0925..ff7b54a 100644 --- a/src/6_future_example.md +++ b/src/6_future_example.md @@ -677,7 +677,7 @@ The last point is relevant when we move on the the last paragraph. > also look at ways to fix it. For now, just make a note of it so you're aware > of the problem. -## Async/Await and concurrecy +## Async/Await and concurrency The `async` keyword can be used on functions as in `async fn(...)` or on a block as in `async { ... }`. Both will turn your function, or block, into a diff --git a/src/conclusion.md b/src/conclusion.md index 942ce5a..17d6dec 100644 --- a/src/conclusion.md +++ b/src/conclusion.md @@ -30,7 +30,7 @@ thing in a slightly different way to get some inspiration. * Do you want to pass around a reference to this information using an `Arc`? * Do you want to make a global `Reactor` so it can be accessed from anywhere? -### Building a better exectuor +### Building a better executor Right now, we can only run one and one future only. Most runtimes has a `spawn` function which let's you start off a future and `await` it later so you