This commit is contained in:
Carl Fredrik Samson
2021-01-14 21:25:44 +01:00
parent df6c6f98d4
commit d06e85aa46
3 changed files with 5 additions and 5 deletions

View File

@@ -165,7 +165,7 @@ future through the `Future` trait.
the `async` and `await` keywords.
3. A defined interface to wake up a suspended task through the `Waker` type.
That's really what Rusts standard library does. As you see there is no definition
That's really what Rust's standard library does. As you see there is no definition
of non-blocking I/O, how these tasks are created, or how they're run.
## I/O vs CPU intensive tasks
@@ -235,7 +235,7 @@ Take a break or a cup of coffee and get ready as we go for a deep dive in the ne
If you find the concepts of concurrency and async programming confusing in
general, I know where you're coming from and I have written some resources to
try to give a high-level overview that will make it easier to learn Rusts
try to give a high-level overview that will make it easier to learn Rust's
Futures afterwards:
* [Async Basics - The difference between concurrency and parallelism](https://cfsamson.github.io/book-exploring-async-basics/1_concurrent_vs_parallel.html)

View File

@@ -4,7 +4,7 @@
>
>- Understand how the async/await syntax works under the hood
>- See first hand why we need `Pin`
>- Understand what makes Rusts async model very memory efficient
>- Understand what makes Rust's async model very memory efficient
>
>The motivation for `Generator`s can be found in [RFC#2033][rfc2033]. It's very
>well written and I can recommend reading through it (it talks as much about
@@ -301,7 +301,7 @@ impl Generator for GeneratorA {
If you try to compile this you'll get an error (just try it yourself by pressing play).
What is the lifetime of `&String`. It's not the same as the lifetime of `Self`. It's not `static`.
Turns out that it's not possible for us in Rusts syntax to describe this lifetime, which means, that
Turns out that it's not possible for us in Rust's syntax to describe this lifetime, which means, that
to make this work, we'll have to let the compiler know that _we_ control this correctly ourselves.
That means turning to unsafe.

View File

@@ -25,7 +25,7 @@ to govern the rules that need to apply for types which implement `!Unpin`.
Yep, you're right, that's double negation right there. `!Unpin` means
"not-un-pin".
> _This naming scheme is one of Rusts safety features where it deliberately
> _This naming scheme is one of Rust's safety features where it deliberately
> tests if you're too tired to safely implement a type with this marker. If
> you're starting to get confused, or even angry, by `!Unpin` it's a good sign
> that it's time to lay down the work and start over tomorrow with a fresh mind._