Rust does not provide any specific isolation between threads' memory. You can Send an &mut T to another thread, and it will be able to mutate your memory.

> You can Send an &mut T to another thread, and it will be able to mutate your memory.

Mutable references are exclusive. If you Send an &mut T to another thread then it isn't really your memory any more—you can't read from it or write to it unless the other thread somehow Sends the reference back.

If it gets sent back or if it ends execution, which releases the &mut T, and the borrow. It isn't your memory temporarily. If it was forever, you'd be passing ownership, not a reference.

In other words, Rust provides the isolation that was originally mentioned.

That there are mechanisms by which the isolation boundary can shift does not change that.

I guess we’re arguing about definitions :) nothing about this is specific to threads, and to me, thread isolation means that threads are forbidden from writing to each other’s memory entirely. Maybe my understanding of the definition is idiosyncratic!

I think the point that verdagon was making regarding "isolation" was that the Rust ownership and borrowing rules prevent any concurrency issues from arising. At the OS level threads, by definition, share all their memory—that's the primary factor that distinguishes them from processes—so it doesn't really make sense to talk about memory belonging to a particular thread at that level. Most other languages do not have that level of isolation and would not actively prevent multiple threads from accessing the same mutable memory location.

In one sense it's true that in Rust terms the actual ownership of the memory remains with the original thread, and the receiving thread is only borrowing it, but the reality is a bit stricter than that would imply since the borrowing thread has exclusive access for the duration of the borrow and can't be forced to give it up. To me, "which stack was the object allocated from" is less important than "which thread actually has control right now".

Yeah, and it's possible I'm over-indexing on something like an Erlang-style green thread model, where shared state is (almost) forbidden, and thinking that's what was being referred to.