== Quote from Steven Schveighoffer ([email protected])'s article > I think in general containers don't work across multiple threads unless > specifically designed to do that.
I'm making the assumption that you'd handle all the synchronization issues yourself. When you need to update the container, there's an obvious issue. In general I don't like the trend in D of building things into arrays, containers, etc. such that they can't be shared across threads due to obscure implementation details even when it looks safe. (For arrays, I'm referring to the appending issue, which is problematic when I try to append to an array from multiple threads, synchronizing manually.) > dcollections containers would probably all fail if you tried to use them > from multiple threads. > That being said, I'm not a huge fan of reference counting period. > Containers have no business being reference counted anyways, since their > resource is memory, and should be handled by the GC. This doesn't mean > pieces of it shouldn't be reference counted or allocated via malloc or > whatever, but the object itself's lifetime should be managed by the GC > IMO. Not coincidentally, this is how dcollections is set up. I think reference counting is an elegant solution to a niche problem (namely, memory management of large containers that won't have circular references when memory is tight), but given all the baggage it creates, I don't think it should be the default for any container. I think we need to start thinking about custom allocators, and allow reference counting but make GC the default.
