diff --git a/src/unsafe-deep-dive/case-studies/intrusive-linked-list.md b/src/unsafe-deep-dive/case-studies/intrusive-linked-list.md index 8bde9c2380b6..d595d0427321 100644 --- a/src/unsafe-deep-dive/case-studies/intrusive-linked-list.md +++ b/src/unsafe-deep-dive/case-studies/intrusive-linked-list.md @@ -3,7 +3,7 @@ > Current as of tokio v1.48.0 The Tokio project maintains an [intrusive linked list implementation][ill] that -demonstrates many use cases of `unsafe` and a number of types and traits from +demonstrates several use cases of `unsafe` and a number of types and traits from Rust's unsafe ecosystem, including `cell::UnsafeCell`, `mem::ManuallyDrop`, [pinning](../pinning/what-pinning-is.md), and unsafe traits. @@ -99,7 +99,7 @@ struct PointersInner { ## Remarks Understanding the whole implementation will take some time, but it's a rewarding -experience. The code demonstrates composing many parts of unsafe Rust's +experience. The code demonstrates composing multiple parts of unsafe Rust's ecosystem into a workable, high performance data structure. Enjoy exploring! [ill]: https://docs.rs/tokio/1.48.0/src/tokio/util/linked_list.rs.html diff --git a/src/unsafe-deep-dive/introduction/characteristics-of-unsafe-rust/sometimes-necessary.md b/src/unsafe-deep-dive/introduction/characteristics-of-unsafe-rust/sometimes-necessary.md index a39d2ec3e354..614ac8a66c5f 100644 --- a/src/unsafe-deep-dive/introduction/characteristics-of-unsafe-rust/sometimes-necessary.md +++ b/src/unsafe-deep-dive/introduction/characteristics-of-unsafe-rust/sometimes-necessary.md @@ -23,7 +23,7 @@ block.” Optional: -“Working with the external environment often involves sharing memory. The +“Working with the external environment frequently involves sharing memory. The interface that computers provide is a memory address (a pointer).” “Here's an example that asks the Linux kernel to write to memory that we diff --git a/src/unsafe-deep-dive/introduction/warm-up/unsafe-fn.md b/src/unsafe-deep-dive/introduction/warm-up/unsafe-fn.md index e7b86f0aecc3..0e76bebb56d0 100644 --- a/src/unsafe-deep-dive/introduction/warm-up/unsafe-fn.md +++ b/src/unsafe-deep-dive/introduction/warm-up/unsafe-fn.md @@ -40,14 +40,14 @@ responsibility for guarding against invalid inputs, or we can shift that responsibility to the caller with the unsafe keyword.” “The first path is a difficult one. We’re accepting a generic type T, which is -all possible types that implement Sized. That’s a lot of types! +all possible types that implement Sized. That is a vast number of types! “Therefore, the second path makes more sense. _Extra content (time permitting)_ “By the way, if you’re interested in the details of pointers and what the rules -of converting them to references are, the standard library has a lot of useful +of converting them to references are, the standard library has many useful documentation. You should also look into the source code of many of the methods on std::pointer. diff --git a/src/unsafe-deep-dive/introduction/warm-up/unsafe-impl.md b/src/unsafe-deep-dive/introduction/warm-up/unsafe-impl.md index e200708e2dad..da79736fa20f 100644 --- a/src/unsafe-deep-dive/introduction/warm-up/unsafe-impl.md +++ b/src/unsafe-deep-dive/introduction/warm-up/unsafe-impl.md @@ -20,8 +20,8 @@ impl Sync for LogicalClock {} “Before we take a look at the code, we should double check that everyone knows what a trait is. Is anyone able to explain traits for the rest of the class? -- “Traits are often described as a way to create shared behavior. Thinking about - traits as shared behavior focuses on the syntax of methods and their +- “Traits are commonly described as a way to create shared behavior. Thinking + about traits as shared behavior focuses on the syntax of methods and their signatures. - “There’s also a deeper way to think of traits: as sets of requirements. This emphasizes the shared semantics of the implementing types. @@ -29,11 +29,11 @@ what a trait is. Is anyone able to explain traits for the rest of the class? “Can anyone explain what the `Send` and `Sync` traits are? - If no - - “Send and Sync relate to concurrency. There are many details, but broadly - speaking, Send types can be shared between threads by value. Sync types must - be shared by reference. - - There are many rules to follow to ensure that it’s safe to share data across - thread boundaries. Those rules cannot be checked by the compiler, and + - “Send and Sync relate to concurrency. There are numerous details, but + broadly speaking, Send types can be shared between threads by value. Sync + types must be shared by reference. + - There are strict rules to follow to ensure that it’s safe to share data + across thread boundaries. Those rules cannot be checked by the compiler, and therefore the code author must take responsibility for upholding them. - Arc implements Send and Sync, therefore it’s safe for our clock to as well. - It may be useful to point out that the word _atomic_ has the meaning of