For convenience, there is a file called original_main.rs in the root of the project that contains the code for main.rs that we presented, so you don’t need to save the original content of main.rs. If you write out every example yourself by copying it from the book in your own project, it would be smart to store the original contents of main.rs somewhere before you overwrite it.
I won’t show the entire state machine here since the 39 lines of code using coroutine/wait end up being 170 lines of code when written as a state machine, but our State enum now looks like this:
enum State0 {
Start,
Wait1(Box<dyn Future<Output = String>>),
Wait2(Box<dyn Future<Output = String>>),
Wait3(Box<dyn Future<Output = String>>),
Wait4(Box<dyn Future<Output = String>>),
Wait5(Box<dyn Future<Output = String>>),
Resolved,
}
If you run the program using cargo run, you now get the following output:
Program starting
FIRST POLL – START OPERATION
HTTP/1.1 200 OK
content-length: 11
connection: close
content-type: text/plain; charset=utf-8
date: Tue, xx xxx xxxx 21:05:55 GMT
HelloWorld0
FIRST POLL – START OPERATION
HTTP/1.1 200 OK
content-length: 11
connection: close
content-type: text/plain; charset=utf-8
date: Tue, xx xxx xxxx 21:05:56 GMT
HelloWorld1
FIRST POLL – START OPERATION
HTTP/1.1 200 OK
content-length: 11
connection: close
content-type: text/plain; charset=utf-8
date: Tue, xx xxx xxxx 21:05:58 GMT
HelloWorld2
FIRST POLL – START OPERATION
HTTP/1.1 200 OK
content-length: 11
connection: close
content-type: text/plain; charset=utf-8
date: Tue, xx xxx xxxx 21:06:01 GMT
HelloWorld3
FIRST POLL – START OPERATION
HTTP/1.1 200 OK
content-length: 11
connection: close
content-type: text/plain; charset=utf-8
date: Tue, xx xxx xxxx 21:06:05 GMT
HelloWorld4
ELAPSED TIME: 10.043025
So, you see that our code runs as expected.
Since we called wait on every call to Http::get, the code ran sequentially, which is evident when we look at the elapsed time of 10 seconds.
That makes sense since the delays we asked for were 0 + 1 + 2 + 3 + 4, which equals 10 seconds.
What if we want our futures to run concurrently?
Do you remember we talked about these futures being lazy? Good. So, you know that we won’t get concurrency just by creating a future. We need to poll them to start the operation.
To solve this, we take some inspiration from Tokio and create a function that does just that called join_all. It takes a collection of futures and drives them all to completion concurrently.
Let’s create the last example for this chapter where we do just this.