Remove reference to NoSend in the concurrency guide

[gsingh93]

The concurrency section in the guide refers to the marker::NoSend trait, but that's been replaced with a negative impl on Send. This should be updated.

(A side note, I think the whole chapter is due for an update. The use of Arc and Mutex and how they got rid of compiler errors feels like magic to me. Furthermore, why does MutexGuard not implement Send in the first place? etc.)

[steveklabnik]

I recently re-wrote the concurrency guide, but you're right that the NoSend thing needs fixed. I thought we had an issue for this...

The use of Arc and Mutex and how they got rid of compiler errors feels like magic to me.

Could you maybe elaborate on this a bit more?

[gsingh93]

So while I understand mutexes and reference counting from other languages, I've never worked with a language that enforced safety at compile time. I understand why the compiler doesn't like the original program (where the data would be moved into three different threads), but I don't fully understand why doing

let data = Arc::new(Mutex::new(vec![1u32, 2, 3]));

and then data.clone() followed by data.lock() silences the compiler errors (I get the gist of it, but how it actually happens feels somewhat "magical" to me). I think walking through the types that are returned and how they fix the ownership issues would be helpful here. Explaining why the mutex doesn't implement Send would also help to give an example of when you shouldn't implement Send on an object.

Also, does something need to implement Send to be captured by a move || closure? I think the explanation of Send at the top should explicitly spell this out.

[steveklabnik]

Fair enough, thanks!