doc-book: Improve clarity of Sync in Concurrency #28463
Conversation
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @steveklabnik (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
| @@ -215,29 +220,15 @@ fn main() { | |||
| } | |||
| ``` | |||
|
|
|||
|
|
|||
| If we'd tried to use `Mutex<T>` without wrapping it in an `Arc<T>` we would have | |||
There was a problem hiding this comment.
The above code snippet without Arc will most likely be thought of like this, which gives a "capture of moved value" error...
|
I have incorporated the changes you suggested. Please have a look at them... |
|
Will try to do tonight or tomorrow. |
|
Made a few more improvements... |
| A `u32` is `Send` because we can make a copy. So we create a thread, ask it to calculate | ||
| the answer, and then it `send()`s us the answer over the channel. | ||
| Here we create 10 threads, asking each to calculate the square of a number (`i` | ||
| at the time of `spawn()`), and then `send()` back the answer over the channel. |
There was a problem hiding this comment.
Do you think it is unnecessary to point out "i at the time of spawn()" (yet again)..?
|
I was reading "Closures" and found some scope for improvement in Returning closures:
But shouldn't the primary reading of the error message be "expected a static reference, found an object"? Further, we could point out that one cannot -- create something, turn it into a static object, and then return a static reference to it... The "reference to stack allocated If you agree with me in this, shall I make these changes in this PR (as a second commit), or should I issue a new PR? |
|
@critiqjo yeah, let's keep the two things separate. I'm not sure exactly what you mean, but I'd rather talk about it in a new issue and or PR |
|
@bors: r+ rollup |
|
📌 Commit a0f214e has been approved by |
…labnik Fixes rust-lang#28458 Details about `Arc` may be too soon to be described together with `Sync`... Tell me what you think. r? @steveklabnik
Fixes #28458
Details about
Arcmay be too soon to be described together withSync... Tell me what you think.r? @steveklabnik