From ed81a9e23c33502a429d3bbdb2d8c4568370ad80 Mon Sep 17 00:00:00 2001 From: Wesley Moore Date: Mon, 19 Aug 2019 17:10:28 +1000 Subject: [PATCH] Fix a couple of typos in the book --- docs/src/concepts/futures.md | 2 +- docs/src/concepts/tasks.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/src/concepts/futures.md b/docs/src/concepts/futures.md index 2eea146..d481023 100644 --- a/docs/src/concepts/futures.md +++ b/docs/src/concepts/futures.md @@ -10,7 +10,7 @@ Luckily, concurrent Rust already has two well-known and effective concepts abstr As a quick summary: -- `Send` abstracts over *passing data* in a computation to another concurrent computation (let's call it the receiver), losing access to it on the sender side. In many programming languages, this strategy is commonly implemented, but missing support from the language side expects you to enforce the "losing access" behaviour yourself. This is a regular source of bugs: senders keeping handles to sent things around and maybe even working with them after sending. Rust mitigates this problem by making this behaviour known. Types can be `Send` or not (by implementing the appropriate marker trait), allowing or disallowing sending them around, and the ownership and borrowing rules prevent subsequent access. +- `Send` abstracts over *passing data* in a computation to another concurrent computation (let's call it the receiver), losing access to it on the sender side. In many programming languages, this strategy is commonly implemented, but missing support from the language side, and expects you to enforce the "losing access" behaviour yourself. This is a regular source of bugs: senders keeping handles to sent things around and maybe even working with them after sending. Rust mitigates this problem by making this behaviour known. Types can be `Send` or not (by implementing the appropriate marker trait), allowing or disallowing sending them around, and the ownership and borrowing rules prevent subsequent access. - `Sync` is about *sharing data* between two concurrent parts of a program. This is another common pattern: as writing to a memory location or reading while another party is writing is inherently unsafe, this access needs to be moderated through synchronisation.[^1] There are many common ways for two parties to agree on not using the same part in memory at the same time, for example mutexes and spinlocks. Again, Rust gives you the option of (safely!) not caring. Rust gives you the ability to express that something *needs* synchronisation while not being specific about the *how*. diff --git a/docs/src/concepts/tasks.md b/docs/src/concepts/tasks.md index 2292153..d8c71c9 100644 --- a/docs/src/concepts/tasks.md +++ b/docs/src/concepts/tasks.md @@ -63,10 +63,10 @@ Tasks in `async_std` are one of the core abstractions. Much like Rust's `thread` - They are allocated in one single allocation - All tasks have a *backchannel*, which allows them to propagate results and errors to the spawning task through the `JoinHandle` -- The carry useful metadata for debugging +- They carry useful metadata for debugging - They support task local storage -`async_std`s task api handles setup and teardown of a backing runtime for you and doesn't rely on a runtime being explicitly started. +`async_std`s task API handles setup and teardown of a backing runtime for you and doesn't rely on a runtime being explicitly started. ## Blocking