Async fixes

src/SUMMARY.md

@@ -243,7 +243,7 @@
   - [Pitfalls](async/pitfalls.md)
     - [Blocking the Executor](async/pitfalls/blocking-executor.md)
     - [Pin](async/pitfalls/pin.md)
-    - [Async Traits](async/pitfalls/pin.md)
+    - [Async Traits](async/pitfalls/async-traits.md)
 - [Exercises](exercises/day-4/async.md)
 
 # Final Words

src/async.md

@@ -7,8 +7,8 @@ limited number of threads. This is because the per-task overhead is typically
 very low and operating systems provide primitives for efficiently identifying
 I/O that is able to proceed.
 
-Rust's asynchronous operation is based around "futures", which represent work
-that may be completed in the future. Futures are "polled" until they signal that
+Rust's asynchronous operation is based on "futures", which represent work that
+may be completed in the future. Futures are "polled" until they signal that
 they are complete.
 
 Futures are polled by an async runtime, and several different runtimes are

src/async/channels.md

@@ -18,8 +18,9 @@ async fn ping_handler(mut input: Receiver<()>) {
 async fn main() {
     let (sender, receiver) = mpsc::channel(32);
     let ping_handler_task = tokio::spawn(ping_handler(receiver));
-    for _ in 0..10 {
+    for i in 0..10 {
         sender.send(()).await.expect("Failed to send ping.");
+        println!("Sent {} pings so far.", i + 1);
     }
 
     std::mem::drop(sender);
@@ -29,8 +30,16 @@ async fn main() {
 
 <details>
 
-- Overall, the interface is similar to the `sync` channels as seen in the [morning class](concurrency/channels.md).
-- The `Flume` crate has channels that implement both `sync` and `async` `send` and `recv`. This can be convenient for complex application with both IO and heavy CPU processing tasks.
-- What makes working with `async` channels preferable is the ability to combine them with other `future`s to combine them and create complex control flow.
+* Change the channel size to `3` and see how it affects the execution.
+
+* Overall, the interface is similar to the `sync` channels as seen in the
+  [morning class](concurrency/channels.md).
+
+* The `Flume` crate has channels that implement both `sync` and `async` `send`
+  and `recv`. This can be convenient for complex application with both IO and
+  heavy CPU processing tasks.
+
+* What makes working with `async` channels preferable is the ability to combine
+  them with other `future`s to combine them and create complex control flow.
 
 </details>

src/async/control-flow.md

@@ -1,6 +1,7 @@
 # Futures Control Flow
 
-Futures can be combined together to produce concurrent compute flow graphs. We will cover multiple common operations:
+Futures can be combined together to produce concurrent compute flow graphs. We
+will cover multiple common operations:
 
 ----
 

src/async/futures.md

@@ -15,7 +15,11 @@ async fn count_to(count: i32) -> i32 {
 
 #[tokio::main]
 async fn main() {
-    let _: () = count_to(13);
+    println!("Final count is: {}!", count_to(13).await);
+
+    // Uncomment the following line to see the return type of the async call.
+    // let _: () = count_to(13);
+
 }
 ```
 
@@ -49,10 +53,6 @@ block to pause until that Future is ready, and then evaluates to its output.
 
 <details>
 
-* Run the example and look at the error message. `_: () = ..` is a common
-  technique for getting the type of an expression. Try adding a `.await` in
-  `main`.
-
 * The `Future` and `Poll` types are conceptually quite simple, and implemented as
   such in `std::task`.