rebuild GitHub Pages from generated-book

ch17-00-async-await.html

@@ -292,7 +292,7 @@ <h3 id="parallelism-and-concurrency"><a class="header" href="#parallelism-and-co
 <p>Now, let’s dive into how async programming in Rust actually works! In the rest
 of this chapter, we will:</p>
 <ul>
-<li>see how to use Rust’s <code>async</code> and <code>.await</code> syntax</li>
+<li>see how to use Rust’s <code>async</code> and <code>await</code> syntax</li>
 <li>explore how to use the async model to solve some of the same challenges we
 looked at in Chapter 16</li>
 <li>look at how multithreading and async provide complementary solutions, which

ch17-01-futures-and-syntax.html

@@ -487,13 +487,11 @@ <h3 id="our-first-async-program"><a class="header" href="#our-first-async-progra
 <pre><pre class="playground"><code class="language-rust edition2021"><span class="boring">#![allow(unused)]
 </span><span class="boring">fn main() {
 </span><span class="boring">extern crate trpl; // required for mdbook test
+</span><span class="boring">
 </span>enum PageTitleFuture&lt;'a&gt; {
-    GetAwaitPoint {
-        url: &amp;'a str,
-    },
-    TextAwaitPoint {
-        response: trpl::Response,
-    },
+    Initial { url: &amp;'a str },
+    GetAwaitPoint { url: &amp;'a str },
+    TextAwaitPoint { response: trpl::Response },
 }
 <span class="boring">}</span></code></pre></pre>
 <p>Writing that out by hand would be tedious and error-prone, especially when
@@ -560,8 +558,15 @@ <h3 id="our-first-async-program"><a class="header" href="#our-first-async-progra
 <p>In Listing 17-5, we begin by calling <code>page_title</code> with both of the user-supplied
 URLs. We save the futures produced by calling <code>page_title</code> as <code>title_fut_1</code> and
 <code>title_fut_2</code>. Remember, these don’t do anything yet, because futures are lazy,
-and we have not yet awaited them. Then we pass the futures  <code>trpl::race</code>, which
-returns a value to indicate which of the futures passed to it finishes first.</p>
+and we have not yet awaited them. Then we pass the futures to <code>trpl::race</code>,
+which returns a value to indicate which of the futures passed to it finishes
+first.</p>
+<section class="note" aria-role="note">
+<p>Note: Under the hood, <code>race</code> is built on a more general function, <code>select</code>,
+which you will encounter more often in real-world Rust code. A <code>select</code>
+function can do a lot of things that <code>trpl::race</code> function cannot, but it also
+has some additional complexity that we can skip over for now.</p>
+</section>
 <p>Either future can legitimately “win,” so it does not make sense to return a
 <code>Result</code>. Instead, <code>race</code> returns a type we have not seen before,
 <code>trpl::Either</code>. The <code>Either</code> type is somewhat like a <code>Result</code>, in that it has

ch17-02-concurrency-with-async.html

@@ -229,7 +229,7 @@ <h3 id="counting"><a class="header" href="#counting">Counting</a></h3>
 <p>Then we write two loops within that block, each with a <code>trpl::sleep</code> call in it,
 which waits for half a second (500 milliseconds) before sending the next
 message. We put one loop in the body of a <code>trpl::spawn_task</code> and the other in a
-top-level <code>for</code> loop. We also add an <code>.await</code> after the <code>sleep</code> calls.</p>
+top-level <code>for</code> loop. We also add an <code>await</code> after the <code>sleep</code> calls.</p>
 <p>This does something similar to the thread-based implementation—including the
 fact that you may see the messages appear in a different order in your own
 terminal when you run it.</p>
@@ -277,7 +277,7 @@ <h3 id="counting"><a class="header" href="#counting">Counting</a></h3>
         handle.await.unwrap();
 <span class="boring">    });
 </span><span class="boring">}</span></code></pre></pre>
-<figcaption>Listing 17-7: Using <code>.await</code> with a join handle to run a task to completion</figcaption>
+<figcaption>Listing 17-7: Using <code>await</code> with a join handle to run a task to completion</figcaption>
 </figure>
 <p>This updated version runs till <em>both</em> loops finish.</p>
 <!-- Not extracting output because changes to this output aren't significant;
@@ -298,7 +298,7 @@ <h3 id="counting"><a class="header" href="#counting">Counting</a></h3>
 hi number 9 from the first task!
 </code></pre>
 <p>So far, it looks like async and threads give us the same basic outcomes, just
-with different syntax: using <code>.await</code> instead of calling <code>join</code> on the join
+with different syntax: using <code>await</code> instead of calling <code>join</code> on the join
 handle, and awaiting the <code>sleep</code> calls.</p>
 <p>The bigger difference is that we did not need to spawn another operating system
 thread to do this. In fact, we do not even need to spawn a task here. Because
@@ -459,7 +459,7 @@ <h3 id="message-passing"><a class="header" href="#message-passing">Message Passi
         }
 <span class="boring">    });
 </span><span class="boring">}</span></code></pre>
-<figcaption>Listing 17-10: Sending and receiving multiple messages over the async channel and sleeping with an <code>.await</code> between each message</figcaption>
+<figcaption>Listing 17-10: Sending and receiving multiple messages over the async channel and sleeping with an <code>await</code> between each message</figcaption>
 </figure>
 <p>In addition to sending the messages, we need to receive them. In this case, we
 could do that manually, by just doing <code>rx.recv().await</code> four times, because we
@@ -493,13 +493,13 @@ <h3 id="message-passing"><a class="header" href="#message-passing">Message Passi
 class="keystroke">ctrl-c</span>.</p>
 <p>Let’s start by understanding why the messages all come in at once after the full
 delay, rather than coming in with delays in between each one. Within a given
-async block, the order that <code>.await</code> keywords appear in the code is also the
+async block, the order that <code>await</code> keywords appear in the code is also the
 order they happen when running the program.</p>
 <p>There is only one async block in Listing 17-10, so everything in it runs
 linearly. There is still no concurrency. All the <code>tx.send</code> calls happen,
 interspersed with all of the <code>trpl::sleep</code> calls and their associated await
-points. Only then does the <code>while let</code> loop get to go through any of the
-<code>.await</code> points on the <code>recv</code> calls.</p>
+points. Only then does the <code>while let</code> loop get to go through any of the <code>await</code>
+points on the <code>recv</code> calls.</p>
 <p>To get the behavior we want, where the sleep delay happens between receiving
 each message, we need to put the <code>tx</code> and <code>rx</code> operations in their own async
 blocks. Then the runtime can execute each of them separately using <code>trpl::join</code>,

ch17-03-more-futures.html

@@ -728,22 +728,15 @@ <h3 id="racing-futures"><a class="header" href="#racing-futures">Racing futures<
 <p>When we “join” futures with the <code>join</code> family of functions and macros, we
 require <em>all</em> of them to finish before we move on. Sometimes, though, we only
 need <em>some</em> future from a set to finish before we move on—kind of like racing
-one future against another. This operation is often named <code>race</code> for exactly
-that reason.</p>
-<section class="note" aria-role="note">
-<p>Note: Under the hood, <code>race</code> is built on a more general function, <code>select</code>,
-which you will encounter more often in real-world Rust code. A <code>select</code>
-function can do a lot of things that <code>trpl::race</code> function cannot, but it also
-has some additional complexity that we can skip over for now.</p>
-</section>
-<p>In Listing 17-21, we use <code>trpl::race</code> to run two futures, <code>slow</code> and <code>fast</code>,
-against each other. Each one prints a message when it starts running, pauses for
-some amount of time by calling and awaiting <code>sleep</code>, and then prints another
-message when it finishes. Then we pass both to <code>trpl::race</code> and wait for one of
-them to finish. (The outcome here won’t be too surprising: <code>fast</code> wins!) Note
-that unlike the first time we used <code>race</code> back in <a href="ch17-01-futures-and-syntax.html#our-first-async-program">Our First Async
-Program</a>, we just ignore the <code>Either</code> instance it returns here,
-because all of the interesting behavior happens in the body of the async blocks.</p>
+one future against another.</p>
+<p>In Listing 17-21, we once again use <code>trpl::race</code> to run two futures, <code>slow</code> and
+<code>fast</code>, against each other. Each one prints a message when it starts running,
+pauses for some amount of time by calling and awaiting <code>sleep</code>, and then prints
+another message when it finishes. Then we pass both to <code>trpl::race</code> and wait for
+one of them to finish. (The outcome here won’t be too surprising: <code>fast</code> wins!)
+Unlike when we used <code>race</code> back in <a href="ch17-01-futures-and-syntax.html#our-first-async-program">Our First Async Program</a>, we
+just ignore the <code>Either</code> instance it returns here, because all of the
+interesting behavior happens in the body of the async blocks.</p>
 <figure class="listing">
 <span class="file-name">Filename: src/main.rs</span>
 <pre><pre class="playground"><code class="language-rust edition2021"><span class="boring">extern crate trpl; // required for mdbook test
@@ -775,7 +768,7 @@ <h3 id="racing-futures"><a class="header" href="#racing-futures">Racing futures<
 not fair. It always runs the futures passed as arguments in the order they are
 passed. Other implementations <em>are</em> fair, and will randomly choose which future
 to poll first. Regardless of whether the implementation of race we are using is
-fair, though, <em>one</em> of the futures will run up to the first <code>.await</code> in its body
+fair, though, <em>one</em> of the futures will run up to the first <code>await</code> in its body
 before another task can start.</p>
 <p>Recall from <a href="ch17-01-futures-and-syntax.html#our-first-async-program">Our First Async Program</a> that at each await point,
 Rust gives a runtime a chance to pause the task and switch to another one if the
@@ -1196,7 +1189,7 @@ <h3 id="building-our-own-async-abstractions"><a class="header" href="#building-o
 using smaller async building blocks. For example, you can use this same approach
 to combine timeouts with retries, and in turn use those with things like network
 calls—one of the examples from the beginning of the chapter!</p>
-<p>In practice, you will usually work directly with <code>async</code> and <code>.await</code>, and
+<p>In practice, you will usually work directly with <code>async</code> and <code>await</code>, and
 secondarily with functions and macros like <code>join</code>, <code>join_all</code>, <code>race</code>, and so
 on. You will only need to reach for <code>pin</code> now and again to use them with those
 APIs.</p>

ch17-04-streams.html

@@ -268,13 +268,13 @@ <h2 id="streams"><a class="header" href="#streams">Streams</a></h2>
 method and also many other utility methods like those from <code>Iterator</code>. We will
 return to the <code>Stream</code> and <code>StreamExt</code> traits in a bit more detail at the end of
 the chapter. For now, this is enough to let us keep moving.</p>
-<p>All we need to do here is add a <code>use</code> statement for <code>trpl::StreamExt</code>, as in
-Listing 17-31.</p>
+<p>All we need to do is add a <code>use</code> statement for <code>trpl::StreamExt</code>, as in Listing
+17-31.</p>
 <figure class="listing">
 <span class="file-name">Filename: src/main.rs</span>
-<pre><code class="language-rust ignore does_not_compile">extern crate trpl; // required for mdbook test
-
-use trpl::StreamExt;
+<pre><code class="language-rust ignore does_not_compile"><span class="boring">extern crate trpl; // required for mdbook test
+</span><span class="boring">
+</span>use trpl::StreamExt;
 
 fn main() {
     trpl::run(async {
@@ -295,9 +295,9 @@ <h2 id="streams"><a class="header" href="#streams">Streams</a></h2>
 method to filter out everything but multiples of three and five.</p>
 <figure class="listing">
 <span class="file-name">Filename: src/main.rs</span>
-<pre><pre class="playground"><code class="language-rust edition2021">extern crate trpl; // required for mdbook test
-
-use trpl::StreamExt;
+<pre><pre class="playground"><code class="language-rust edition2021"><span class="boring">extern crate trpl; // required for mdbook test
+</span><span class="boring">
+</span>use trpl::StreamExt;
 
 fn main() {
     trpl::run(async {
@@ -925,9 +925,9 @@ <h3 id="merging-streams"><a class="header" href="#merging-streams">Merging Strea
 }</code></pre></pre>
 <figcaption>Listing 17-40: Handling errors and shutting down the loops</figcaption>
 </figure>
-<p>That is a good note to turn to our final section and wrap up this walk through
-async in Rust, by discussing how futures (including streams), tasks, and threads
-relate to each other, and how you can use them together.</p>
+<p>Now that we have seen a bunch of async in practice, let’s take a step back and
+dig into a few of the details of how <code>Future</code>, <code>Stream</code>, and the other key
+traits which Rust uses to make async work.</p>
 
                     </main>