3 ms·

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

• steveklabnik 6y ago
  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!
  • nybble41 6y ago
    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".
    • steveklabnik 6y ago
      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.