diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index 58c4c5ddea3..f417f854b74 100644
--- a/src/SUMMARY.md
+++ b/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
diff --git a/src/async.md b/src/async.md
index cd2487dd522..28d39cfd8b5 100644
--- a/src/async.md
+++ b/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
diff --git a/src/async/channels.md b/src/async/channels.md
index bd3df621360..65b0754341c 100644
--- a/src/async/channels.md
+++ b/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() {
-- 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.
diff --git a/src/async/control-flow.md b/src/async/control-flow.md
index b0158d87b04..5e5b950e2cf 100644
--- a/src/async/control-flow.md
+++ b/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:
----
diff --git a/src/async/futures.md b/src/async/futures.md
index 18ef41b80c1..595fb3e56ab 100644
--- a/src/async/futures.md
+++ b/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.
-* 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`.