New upstream version 1.62.1+dfsg1

[rustc.git] / src / doc / book / src / ch16-04-extensible-concurrency-sync-and-send.md

diff --git a/src/doc/book/src/ch16-04-extensible-concurrency-sync-and-send.md b/src/doc/book/src/ch16-04-extensible-concurrency-sync-and-send.md
index 4104e83d8e860163c3151726f14adb13ad2942ab..4586b8d2c4fba4417a10e34ea3036258f149d6c1 100644 (file)
--- a/src/doc/book/src/ch16-04-extensible-concurrency-sync-and-send.md
+++ b/src/doc/book/src/ch16-04-extensible-concurrency-sync-and-send.md
@@ -11,13 +11,14 @@ However, two concurrency concepts are embedded in the language: the
 
 ### Allowing Transference of Ownership Between Threads with `Send`
 
-The `Send` marker trait indicates that ownership of values of the type implementing
-`Send` can be transferred between threads. Almost every Rust type is `Send`,
-but there are some exceptions, including `Rc<T>`: this cannot be `Send` because
-if you cloned an `Rc<T>` value and tried to transfer ownership of the clone to
-another thread, both threads might update the reference count at the same time.
-For this reason, `Rc<T>` is implemented for use in single-threaded situations
-where you don’t want to pay the thread-safe performance penalty.
+The `Send` marker trait indicates that ownership of values of the type
+implementing `Send` can be transferred between threads. Almost every Rust type
+is `Send`, but there are some exceptions, including `Rc<T>`: this cannot be
+`Send` because if you cloned an `Rc<T>` value and tried to transfer ownership
+of the clone to another thread, both threads might update the reference count
+at the same time. For this reason, `Rc<T>` is implemented for use in
+single-threaded situations where you don’t want to pay the thread-safe
+performance penalty.
 
 Therefore, Rust’s type system and trait bounds ensure that you can never
 accidentally send an `Rc<T>` value across threads unsafely. When we tried to do