> But this is for example about general cfg that is read from a file before any > thread starts and which doesn't change
In that case it is indeed fine, the address is a global which is guaranteed to survive until the whole program exits. > So - you are telling me to not use arc when using threads? I thought that arc > could become the next default gc. No, ARC (ref object) solves sharing memory so that it can be collected by any thread. When you have shared ownership, you need an atomic reference counter or guarantees by design that the object won't be collected (ancestor threads are the owners and responsible for creation deletion) or fancier memory management techniques like hazard pointers or epoch-based reclamation or quiescent-based reclamation. ARC (ref object) is still correct for any object that does not have joint ownership between 2 or more threads. > Would it make sense to create some ref counted datatype that can be shared > more easily in threads, similar to shared_ptr in c++? Not sure if this is a > good idea, as even shared_ptr in c++ have their traps that require to use > atomic_shared_ptrs in some situations. Just thinking out loud. C++ Shared pointers have the same issue as ARC, they are not threadsafe and only usable when at any point in time only a single thread can access and mutate those objects which is guaranteed if using Communicating Sequential Processes architecture (aka Producer-Consumer or Channel-based architecture). A threadsafe shared smartpointer is mentioned in my very first reply > * Or you use atomic refcounting: > <https://github.com/nim-lang/threading/blob/49562fa0/threading/smartptrs.nim#L77-L132> >
