update original

rustbook-en/src/ch21-00-final-project-a-web-server.md

@@ -20,14 +20,22 @@ Here is our plan for building the web server:
 4. Create a proper HTTP response.
 5. Improve the throughput of our server with a thread pool.
 
-Before we get started, we should mention one detail: the method we’ll use won’t
-be the best way to build a web server with Rust. Community members have
-published a number of production-ready crates available on
-[crates.io](https://crates.io/) that provide more complete web server and
-thread pool implementations than we’ll build. However, our intention in this
-chapter is to help you learn, not to take the easy route. Because Rust is a
-systems programming language, we can choose the level of abstraction we want to
-work with and can go to a lower level than is possible or practical in other
-languages. We’ll therefore write the basic HTTP server and thread pool manually
-so you can learn the general ideas and techniques behind the crates you might
-use in the future.
+Before we get started, we should mention two details: First, the method we’ll
+use won’t be the best way to build a web server with Rust. Community members
+have published a number of production-ready crates available on
+[crates.io](https://crates.io/) that provide more complete web server and thread
+pool implementations than we’ll build. However, our intention in this chapter is
+to help you learn, not to take the easy route. Because Rust is a systems
+programming language, we can choose the level of abstraction we want to work
+with and can go to a lower level than is possible or practical in other
+languages.
+
+Second, we will not be using async and await here. Building a thread pool is a
+big enough challenge on its own, without adding in building an async runtime!
+However, we will note how async and await might be applicable to some of the
+same problems we will see in this chapter. Ultimately, as we noted back in
+Chapter 17, many async runtimes use thread pools for managing their work.
+
+We’ll therefore write the basic HTTP server and thread pool manually so you can
+learn the general ideas and techniques behind the crates you might use in the
+future.

rustbook-en/src/ch21-02-multithreaded.md

@@ -43,7 +43,8 @@ But if you enter */sleep* and then load */*, you’ll see that */* waits until
 `sleep` has slept for its full 5 seconds before loading.
 
 There are multiple techniques we could use to avoid requests backing up behind
-a slow request; the one we’ll implement is a thread pool.
+a slow request, including using async as we did Chapter 17; the one we’ll
+implement is a thread pool.
 
 ### Improving Throughput with a Thread Pool
 
@@ -120,6 +121,10 @@ that the requests to */* don’t have to wait for */sleep* to finish. However, a
 we mentioned, this will eventually overwhelm the system because you’d be making
 new threads without any limit.
 
+You may also recall from Chapter 17 that this is exactly the kind of situation
+where async and await really shine! Keep that in mind as we build the thread
+pool and think about how things would look different or the same with async.
+
 <!-- Old headings. Do not remove or links may break. -->
 <a id="creating-a-similar-interface-for-a-finite-number-of-threads"></a>
 
@@ -291,6 +296,9 @@ yet!
 > writing unit tests to check that the code compiles *and* has the behavior we
 > want.
 
+Consider: what would be different here if we were going to execute a *future*
+instead of a closure?
+
 #### Validating the Number of Threads in `new`
 
 We aren’t doing anything with the parameters to `new` and `execute`. Let’s
@@ -657,6 +665,11 @@ thread run them.
 > multiple instances of the same request sequentially for caching reasons. This
 > limitation is not caused by our web server.
 
+This is a good time to pause and consider how the code in Listings 21-18, 21-19,
+and 21-20 would be different if we were using futures instead of a closure for
+the work to be done. What types would change? How would the method signatures be
+different, if at all? What parts of the code would stay the same?
+
 After learning about the `while let` loop in Chapters 17 and 18, you might be
 wondering why we didn’t write the worker thread code as shown in Listing 21-21.
 

rustbook-en/src/ch21-03-graceful-shutdown-and-cleanup.md

@@ -15,6 +15,10 @@ accepting new requests and shut down. To see this code in action, we’ll modify
 our server to accept only two requests before gracefully shutting down its
 thread pool.
 
+One thing to notice as we go: none of this affects the parts of the code that
+handle executing the closures, so everything here would be just the same if we
+were using a thread pool for an async runtime.
+
 ### Implementing the `Drop` Trait on `ThreadPool`
 
 Let’s start with implementing `Drop` on our thread pool. When the pool is