-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
thread5.rs does not need Arc #44
Comments
This is very true! Although in your case, actual copies of the string are passed to each thread, and the Arc case shared references are passed. Would only notice if the string was truly enormous! So let me think how to frame this example where the difference is more obvious. |
Perhaps also use a struct (that doesn't implement Copy) so the benefit of Arc is clear. WIth a String, one can just use a &str, ending up not needing the owned variety to see the benefit. Am not sure though if I understand this well? |
If we used a &str reference originally, then we'll always get a 'does not live long enough' error. Putting the reference into an Arc doesn't help that - it remains a reference. I think I will emphasize that the |
Have a look at the change - you can still |
I din't get the long life complaint when I used &str. See https://gist.github.com/tshepang/237d547c38e435144d6fe1887068d33e. |
Puzzled me until I realized that let string = "dolly".to_string();
let name: &str = &string; |
This would also work, |
Rust is not easy |
Well, this has really helped me with a delicate piece of explanation. Ultimately, plain references don't work in threads because they have too short a lifetime to work with |
It runs fine if I remove Arc wrapper. This is 7-shared-and-networking.md
The text was updated successfully, but these errors were encountered: