I have found that ORC + multithreading do not mix in the way one might expect
imo. The mental model from Java, Go, C# etc is not transferable for those that
expect it. Took me a long time to really internalize that for some reason when
coming from that background myself.
Possibly you already know all of this but I'll put it here in case others are
interested or if maybe some could correct my understanding.
It is not correct or safe to share a ref object between multiple threads. Doing
so will result in broken behavior for ARC, even if you manually manage the ref
count since it cannot be bulletproof as it is not atomic nor lockable. For ORC
there are easy to create crashes since iirc the cycle check list is a
threadlocal. Marking ref objects as {.acyclic.} will resolve the ORC
threadlocal cycle check list issue but then you still need to be both careful
not to create cycles and still cannot share references across threads safely.
Assuming a ref object is only ever used / referenced from one thread and
carefully moved across threads, ORC and multithreading can work without issue
in my experience. I do not have issues, crashes etc in Mummy in my usage. I was
quite careful with how I managed the one or two ref types I have, only using
them internally and just manually managing memory for shared resources.
While the care needed to give ref objects in a multithreaded setting is
different from other langs, the shared heap is still such a huge improvement
over refc that I'm very happy with what is now possible.
