diff --git a/Applying Async.md b/Applying Async.md
new file mode 100644
index 0000000..c38bef2
--- /dev/null
+++ b/Applying Async.md
@@ -0,0 +1 @@
+# Applying Concurrency with Async
diff --git a/Async, Await, Futures and Streams.md b/Async, Await, Futures and Streams.md
index c51d906..01a0403 100644
--- a/Async, Await, Futures and Streams.md
+++ b/Async, Await, Futures and Streams.md
@@ -1,13 +1,15 @@
# Fundamentals of Asynchronous Programming: Async, Await, Futures, and Streams
+
Many of the operations we ask computers to do can take a while to finish.
While waiting for that task it would be nice to do something else while we are waiting for those long-running processes to complete.
Modern computers offer two techniques while working on more than one operation at a time:
+
- Parallelism
- Concurrency
-Once we start writing programs that involve parallel or concurrent operations, we quickly encounter new challenges inherit to *asynchronous programming*.
+Once we start writing programs that involve parallel or concurrent operations, we quickly encounter new challenges inherit to _asynchronous programming_.
This is where operations may not finish sequentially in the order they were started.
@@ -19,9 +21,9 @@ We will consider this example.
Say you are exporting a video you created of a family celebration, an operation that could take anywhere from minutes to hours.
-The video export will use as many resources as available on the GPU and CPU.
+The video export will use as many resources as available on the GPU and CPU.
-If you only had one CPU core and your operating system didn't pause that export until it completed (it executed *synchronously*), you wouldn't be able to do anything else on the computer while that task was running.
+If you only had one CPU core and your operating system didn't pause that export until it completed (it executed _synchronously_), you wouldn't be able to do anything else on the computer while that task was running.
This would be incredibly frustrating experience.
@@ -35,27 +37,27 @@ While you can start reading the data once it starts to arrive, it may take some
Even once the data us all present, if the video is quite large, it could take at least a second or two to load it all.
-The video export is an example of a *CPU-bound* or *compute-bound* operation.
+The video export is an example of a _CPU-bound_ or _compute-bound_ operation.
It is limited by the computer's potential data processing speed within the CPU or GPU, and how much speed it can dedicate to the operation.
-The video download is an example of a *IO-bound* operation because it is limited by the speed of the computer's *input and output*; it can only go as fast as the data can be sent across the network.
+The video download is an example of a _IO-bound_ operation because it is limited by the speed of the computer's _input and output_; it can only go as fast as the data can be sent across the network.
In both of these examples, the operating system's invisible interrupts provide a form of concurrency.
-This concurrency happens only at the level of the entire program: the operating system interrupts one program to let other programs get work done.
+This concurrency happens only at the level of the entire program: the operating system interrupts one program to let other programs get work done.
In many cases, because we understand our programs at a much more granular level than the OS does, we can spot opportunities for concurrency that the operating system can't see.
Lets say we are building a tool to manage file downloads, we should be able to write our program so that starting one download won't lock up the UI, and users should be able to start multiple downloads at the same time.
-Many operating system API's for interacting with the network are *blocking*; that is they block the program's progress until the data they are processing is completely ready.
+Many operating system API's for interacting with the network are _blocking_; that is they block the program's progress until the data they are processing is completely ready.
-Note: This is how *most* functions calls work.
+Note: This is how _most_ functions calls work.
-However, the term *blocking* is usually reserved for function calls that interact with files, the network, or other computer resources.
+However, the term _blocking_ is usually reserved for function calls that interact with files, the network, or other computer resources.
-Due to these cases where an individual program would benefit from the operation being *non*-blocking.
+Due to these cases where an individual program would benefit from the operation being _non_-blocking.
We could avoid blocking our main thread by spawning a dedicated thread to download each file.
@@ -64,20 +66,24 @@ The overhead of those threads would eventually become a problem.
It would be preferable if the call didn't block it in the first place, it would be better if we could write in the same style we use in blocking code.
This would be a similar case/code
+
```rust
let data = fetch_data_from(url).await;
println!("{data}");
```
-This is example what Rust's async (short for *asynchronous*) abstraction gives us.
+
+This is example what Rust's async (short for _asynchronous_) abstraction gives us.
This chapter we will learn about:
+
- Futures and Async Syntax [Section Link Here](./Futures%20and%20Async.md)
-- How to use Rust's `async` and `await` syntax [Section Link Here]()
+- How to use Rust's `async` and `await` syntax [Section Link Here](./Applying%20Async.md)
- How to use the async model to solve some of the same challenges we looked at in Ch 16 [Section Link Here]()
- How multithreading and async provide complementary solutions, that you can combine in many cases [Section Link Here]()
-Before jumping into how async works in practice, we need o take a short detour to discuss the differences between parallelism and concurrency.
+ Before jumping into how async works in practice, we need o take a short detour to discuss the differences between parallelism and concurrency.
## Parallelism and Concurrency
+
So far we treated parallelism and concurrency as mostly interchangeable so far.
Now we need to distinguish between them more precisely, because the differences will now start to show up.
@@ -86,7 +92,7 @@ Consider the different ways a team could split up work on a software project.
You could assign a single member multiple tasks assign each member one task or use a mix of the two approaches.
-When an individual works on several different tasks before any of them is complete, this is *concurrency*.
+When an individual works on several different tasks before any of them is complete, this is _concurrency_.
Or maybe you have two different projects checked out on your computer and when you get bored or stuck on one project, you switch to the other.
@@ -94,17 +100,17 @@ As one person, so you can't make progress on both tasks at the exact same time,
Here is a picture of this
-When the team instead splits up a group of tasks by having each member take one task and work on it alone, this is *parallelism*
+When the team instead splits up a group of tasks by having each member take one task and work on it alone, this is _parallelism_
Each person on the team can make progress at the exact same time.
In both of these workflows, you might have to coordinate between different tasks.
-Maybe it was *thought* that the task was totally independent from every other.
+Maybe it was _thought_ that the task was totally independent from every other.
It actually requires another person on the team to finish their task first..
-Some of this work can be done in parallel, but some of it actually was *serial*: it could only happen in a series, one task after another.
+Some of this work can be done in parallel, but some of it actually was _serial_: it could only happen in a series, one task after another.
Here is a diagram of this
diff --git a/Futures and Async.md b/Futures and Async.md
index cf36a16..a3cdcad 100644
--- a/Futures and Async.md
+++ b/Futures and Async.md
@@ -1 +1,417 @@
# Futures and the Async Syntax
+
+The key parts of asynchronous programming in Rust are _futures_ and Rust's `async` and `await` keywords
+
+A _future_ or a promise is a value that may not be ready now but will become ready at some point in the future
+
+In other lnaguages the same concept shows up under other names such as _task_ or _promise_.
+
+Rust provides a `Future` trait as a building block so that different async operations can be implemented with different data structures but with a common inferface.
+
+Rust futures are types that implement the `Future` trait.
+
+Each future holds its own information about the progress tha has been made and what "ready" means.
+
+You can apply the `async` keyword to blocks and functions to specify that they can be interrupted and resumed.
+
+Within an async block or async funcion, you can use the `await` keyword to _await a future_ (that is, wait for it to become ready).
+
+Any point where you await a future within an async or function is a potential spot for that async block or function to pause and resume.
+
+The process of checking with a future to see if its value is avaialable yet is called _polling_.
+
+Some other languages, uch as C# and JavaScript, that also use `async` and `await` keyowrds for async programming.
+
+There are some significant differences in how Rust does things, including how it handles the syntax.
+
+When writing async Rust, we use the `async` and `await` keywords most of the time.
+
+Rust compiles them into equivalent code using the `Future` trait, much as it compiles `for` loops into equivalent code using the `Iterator` trait.
+
+Due to Rust providing the `Future` trait, this means that you can also implement it for your own data types you need to.
+
+Many of the functions that we will see have return types with their own implmentations of `Future`.
+
+We will return to the definition of the trait at the end of the chapeter and dig into more of how it works.
+
+This may all feel a bit abstract so we will go into our first program: a little web scraper.
+
+We will pass in two urls form the command line, fetch both of them concurrently and reutrn the result of whichever one fiinihes first.
+
+This will have a fair bit of new syntax.
+
+## Our First Async Program
+
+To keep focus on learning async rather than juggling parts of the ecosystem, we created the `trpl` crate (this is sort for "The Rust Programming Language").
+
+This re-exports all the types, traits, and functions you will need, primarily form the [`futures`](https://crates.io/crates/futures) and [`tokio`](https://tokio.rs/) crates.
+
+The `futures` crate is an official home for Rust experimentation for async code, and it is where the `Future` trait was orignially designed.
+
+Tokio is the most widely used `async` runtime in Rust today, especially for web applications.
+
+Here we the `tokio` crate under the hood for `trpl` becuase it is well tested and widly used.
+
+In some cases `trpl` also renames or wraps the original APIs to keep us focused on the details relevant to this chapter.
+
+If you want to undestand in depth of what the crate does, check out [its source code](https://github.com/rust-lang/book/tree/main/packages/trpl).
+
+You will then be albe to see what crate each re-export comes from, and we have left extensive comments explaining what the crate does.
+
+First we will start by building a little command line tools that fetches two we pages, pulls the `
` element from each and print out the title of whichever page finishes that whole process first.
+
+## Defining the `page_title` Function
+
+First we will start by writing a function that takes one page URL as a parameter
+
+```rust
+extern crate trpl; // required for mdbook test
+
+fn main() {
+ // TODO: we'll add this next!
+}
+
+use trpl::Html;
+
+async fn page_title(url: &str) -> Option {
+ let response = trpl::get(url).await;
+ let response_text = response.text().await;
+ Html::parse(&response_text)
+ .select_first("title")
+ .map(|title_element| title_element.inner_html())
+}
+```
+
+Fist we define a fnction named `page_title` and mark it with the `async` keyword.
+
+We then ise the `trpl::get` function to fetch whatever URL is passed in and add the `await` keyword to await the response.
+
+To get the response, we call its `text` method, and once again await it with the `await` keyword.
+
+Both of these steps are asynchronous.
+
+For the `get` function, we have to wait for the server to send back the first part of its response. This will include HTTP header, cookies and so on, and can be delivered separately from the response body.
+
+Especially if the body is very large, it can take some time for it all to arrive.
+
+If we have to wait for the _entirety_ of the response to arrive, the `text` method is also aync.
+
+Here we have to explicity await both of these future, because futures in Rust are _lazy_
+
+Futures will not do anthing until you ask them to with the `await` keyword. (Rust will show a compiler warning if you don't use a future)
+
+This might remind you of iterators in the section [Processing a Series of Items With Iteraors](./Iterators.md).
+
+Iterators do nothing unless you call their `next` method whether directly or by using `for` loops or methods such as `map` that use `next` under the hood.
+
+Likewise, futures do nothing unless you explicitly ask them to.
+
+This laziness allows Rust ot avoid running async code until its actually needed.
+
+This is differnt from the behavoir we say before when unsing `thread::spawn` in [Creating a New Thread with `spawn`](./Simultaneous%20Code%20Running.md#creating-a-new-thread-with-spawn), where the closure we passed to another thead started running immediately.
+
+This is also different from how many other languages approach async.
+
+This is improtant for Rust and we will see why later.
+
+Once we have `response_text`, we can then parse it into an intance of the `Html` type using `Html::parse`.
+
+Instead of a raw string, we now have a data type we can work with the HTML as a richer data structure.
+
+In particular, we can use the `select_first` method to find the first instace of a given CSS selector.
+
+By passing the string `"title"`, we get the first `` element in the document, if there is one.
+
+Becuase there may not be any matching element, `select_first` returns an `Option`.
+
+Lastly we use the `Option::map` method, this lets us work with the item in the `Option` if it is present and do nothing if it isn't.
+
+We could also use a `match` expression, but `map` is more idiomatic.
+
+In the body of the function we supply to `map`, we call `inner_html` on `title_element` to get its content, which is a `String`.
+
+When it is all done we have an `Option`
+
+Note that Rust's `await` kword goes _after_ the expression you are awaiting, not before it.
+
+It is a _postfix_ keyword.
+
+This may differ from what you may have used `async` in other languages, but in Rust it makes chains of methods much nice to work with.
+
+This results that we can change the body of `page_url_for` to chain the `trpl::get` and `text` function calls together with `await` between them.
+
+```rust
+ let response_text = trpl::get(url).await.text().await;
+```
+
+With this we have successfully written our first async function.
+
+Befor we add some code in `main` to call it. We will dive even deep into what we have written and what it means.
+
+When Rust sees a block mared with the `async` keyword, it compiles it into a unique, anonymous data tpye that implements the `Future` trait.
+
+When Rust sees a function marked with `async`, it compiles it nto a non-async function whose body is an async block.
+
+An async function's return type is the type of the anonymous data type the compiler creates for that async block.
+
+Writing `async fn` is equivalent to writing a function that returns a _future_ of the return type.
+
+To the compiler, a function definition such as the `async fn page_title` is equivalent ot a non-async function defined like this:
+
+```rust
+use std::future::Future;
+use trpl::Html;
+
+fn page_title(url: &str) -> impl Future