public-collect/books-futures-explained
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Merge pull request #49 from Inconnu08/patch-1

Browse Source 
Fix grammar and typos
This commit is contained in:
Carl Fredrik Samson
2022-11-07 15:57:16 +01:00
committed by GitHub
parent fbfd42941c 9a26fdd854
commit 2a5aa96677
1 changed files with 11 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
src/conclusion.md
View File

@@ -1,9 +1,9 @@
# Conclusion and exercises # Conclusion and exercises
Congratulations. Good job! If you got this far you must have stayed with me Congratulations. Good job! If you got this far, you must have stayed with me
all the way. I hope you enjoyed the ride! all the way. I hope you enjoyed the ride!
Remember that you call always leave feedback, suggest improvements or ask questions Remember that you can always leave feedback, suggest improvements or ask questions
in the [issue_tracker](https://github.com/cfsamson/books-futures-explained/issues) for this book. in the [issue_tracker](https://github.com/cfsamson/books-futures-explained/issues) for this book.
I'll try my best to respond to each one of them. I'll try my best to respond to each one of them.
@@ -14,7 +14,7 @@ Until next time!
## Reader exercises ## Reader exercises
So our implementation has taken some obvious shortcuts and could use some improvement. So our implementation has taken some obvious shortcuts and could use some improvement.
Actually digging into the code and try things yourself is a good way to learn. Here are Actually, digging into the code and trying things yourself is a good way to learn. Here are
some good exercises if you want to explore more: some good exercises if you want to explore more:
### Avoid wrapping the whole `Reactor` in a mutex and pass it around ### Avoid wrapping the whole `Reactor` in a mutex and pass it around
@@ -32,16 +32,16 @@ thing in a slightly different way to get some inspiration.
### Building a better executor ### Building a better executor
Right now, we can only run one and one future only. Most runtimes has a `spawn` Right now, we can only run one and one future only. Most runtimes have a `spawn`
function which let's you start off a future and `await` it later so you function which let's you start off a future and `await` it later so you
can run multiple futures concurrently. can run multiple futures concurrently.
As I suggested in the start of this book, visiting [@stjepan'sblog series about implementing your own executors](https://web.archive.org/web/20200207092849/https://stjepang.github.io/2020/01/31/build-your-own-executor.html) As I suggested in the start of this book, visiting [@stjepan'sblog series about implementing your own executors](https://web.archive.org/web/20200207092849/https://stjepang.github.io/2020/01/31/build-your-own-executor.html)
is the place I would start and take it from there. You could further examine the source code of [smol - A small and fast async runtime](https://github.com/smol-rs/smol) wich is a good project to learn from. is the place I would start and take it from there. You could further examine the source code of [smol - A small and fast async runtime](https://github.com/smol-rs/smol) which is a good project to learn from.
### Create an unique Id for each task ### Create a unique Id for each task
As we discussed in the end of the main example. What happens if the user pass in As we discussed at the end of the main example. What happens if the user pass in
the same Id for both events? the same Id for both events?
```rust, ignore ```rust, ignore
@@ -49,14 +49,14 @@ let future1 = Task::new(reactor.clone(), 1, 1);
let future2 = Task::new(reactor.clone(), 2, 1); let future2 = Task::new(reactor.clone(), 2, 1);
``` ```
Right now it will deadlock since our `poll` method thinks the first poll of Right now, it will deadlock since our `poll` method thinks the first poll of
`future2` is `future1` getting polled again and swaps out the waker with the `future2` is `future1` getting polled again and swaps out the waker with the
one from `future2`. This waker never gets called since the task is never one from `future2`. This waker never gets called since the task is never
registered. registered.
It's probably a bad idea to expose the user to this behavior, so we It's probably a bad idea to expose the user to this behavior, so we
should have a unique Id for each task which we use internally. There are a should have a unique Id for each task which we use internally. There are many ways to solve this.
many ways to solve this. Below is two suggestions to get going: Below is two suggestions to get going:
1. Let the reactor have a `usize` which is incremented on every task creation 1. Let the reactor have a `usize` which is incremented on every task creation
2. Use a crate like `Guid` to generate an unique Id for each task 2. Use a crate like `Guid` to generate an unique Id for each task
@@ -66,7 +66,7 @@ many ways to solve this. Below is two suggestions to get going:
There are many great resources. In addition to the RFCs and articles I've already There are many great resources. In addition to the RFCs and articles I've already
linked to in the book, here are some of my suggestions: linked to in the book, here are some of my suggestions:
[The official Asyc book](https://rust-lang.github.io/async-book/01_getting_started/01_chapter.html) [The official Async book](https://rust-lang.github.io/async-book/01_getting_started/01_chapter.html)
[Tokio tutorial](https://tokio.rs/tokio/tutorial) [Tokio tutorial](https://tokio.rs/tokio/tutorial)