More comments in solution for cyclic Callbacks

[rust-101.git] / src / part12.rs

diff --git a/src/part12.rs b/src/part12.rs
index 8b04fb669ef23083556b7672b76306bdaf0ab881..c2331eaf618b82aa2ee8e1308512c52b364401cd 100644 (file)
--- a/src/part12.rs
+++ b/src/part12.rs
@@ -71,7 +71,7 @@ pub fn main() {
 fn demo_cell(c: &mut Callbacks) {
     {
         let count = Cell::new(0);
-        // Again, we have to move ownership if the `count` into the environment closure.
+        // Again, we have to move ownership of the `count` into the environment closure.
         c.register(move |val| {
             // In here, all we have is a shared reference of our environment. But that's good enough for the `get` and `set` of the cell!
             //@ At run-time, the `Cell` will be almost entirely compiled away, so this becomes pretty much equivalent to the version
@@ -89,10 +89,10 @@ fn demo_cell(c: &mut Callbacks) {
 //@ is a shared reference. However, it has to increment the reference count! Internally, `Rc` uses `Cell` for the count, such that it
 //@ can be updated during `clone`.
 //@ 
-//@ Putting it all together, the story around mutation and ownership through references looks as follows: There are *exclusive* references,
+//@ Putting it all together, the story around mutation and ownership through references looks as follows: There are *unique* references,
 //@ which - because of their exclusivity - are always safe to mutate through. And there are *shared* references, where the compiler cannot
 //@ generally promise that mutation is safe. However, if extra circumstances guarantee that mutation *is* safe, then it can happen even
-//@ through a sahred reference - as we saw with `Cell`.
+//@ through a shared reference - as we saw with `Cell`.
 
 // ## `RefCell`
 //@ As the next step in the evolution of `Callbacks`, we could try to solve this problem of mutability once and for all, by adding `Cell`
@@ -135,8 +135,8 @@ impl CallbacksMut {
             //@ the check will always succeed, as is actually entirely useless. However, this is not actually true. Several different `CallbacksMut` could share
             //@ a callback (as they were created with `clone`), and calling one callback here could trigger calling
             //@ all callbacks of the other `CallbacksMut`, which would end up calling the initial callback again. This issue of functions accidentally recursively calling
-            //@ themselves is called *reentrancy*, and it can lead to subtle bugs. Here, it would mean that the closure runs twice, each time thinking it has an
-            //@ exclusive, mutable reference to its environment - so it may end up dereferencing a dangling pointer. Ouch! Lucky enough,
+            //@ themselves is called *reentrancy*, and it can lead to subtle bugs. Here, it would mean that the closure runs twice, each time thinking it has a
+            //@ unique, mutable reference to its environment - so it may end up dereferencing a dangling pointer. Ouch! Lucky enough,
             //@ Rust detects this at run-time and panics once we try to borrow the same environment again. I hope this also makes it
             //@ clear that there's absolutely no hope of Rust performing these checks statically, at compile-time: It would have to detect reentrancy!
             let mut closure = callback.borrow_mut();
@@ -166,4 +166,4 @@ fn demo_mut(c: &mut CallbacksMut) {
 // **Exercise 12.1**: Write some piece of code using only the available, public interface of `CallbacksMut` such that a reentrant call to a closure
 // is happening, and the program panics because the `RefCell` refuses to hand out a second mutable borrow of the closure's environment.
 
-//@ [index](main.html) | [previous](part11.html) | [raw source](https://www.ralfj.de/git/rust-101.git/blob_plain/HEAD:/workspace/src/part12.rs) | [next](part13.html)
+//@ [index](main.html) | [previous](part11.html) | [raw source](workspace/src/part12.rs) | [next](part13.html)