On Oct 18, 2012, at 6:06 PM, Michel Fortin <michel.for...@michelf.ca> wrote: > > All this is nice, but what is the owner thread for immutable data? Because > immutable is always implicitly shared, all your strings and everything else > that is immutable is thus "shared" and must be tracked by the global heap's > collector and can never be handled by a thread-local collector. Even if most > immutable data never leaves the thread it was allocated in, there's no way > you can know.
Yes. > I don't think per-thread GCs will work very well without support for > immutable data, an for that you need to have a distinction between immutable > and shared immutable (just like you have with mutable data). I complained > about this almost three years ago when the semantics of shared were being > defined, but it got nowhere. Yeah, that's unfortunate. "shared" today really has two meanings: instance visibility and what happens when the instance is accessed. By comparison, "immutable" just describes what happens when the instance is accessed. The really weird part of all this being that immutable data is exempt from the transitivity requirement of "shared". Though that makes me realize that casting a UDT to "shared" could mean traversing all data reachable by that instance and marking it as shared as well, which sounds absolutely terrible. Perhaps something could be done in instances where the only place data is passed between threads in an app is via std.concurrency? Allowing strings to be referenced by global shared references would still be problematic though. I'll have to give this some thought.
