> It's quite easy to trick even ORC by using GC_ref in sender thread and > GC_unref in receiver thread. Not sure how safe it is tho !
ORC/ARC aren't safe against race conditions on the increment/decrement on refs. So the `GC_ref/GC_unref` can run into race conditions. You'd want to use `wasMoved` to skip the ref/unref steps like in [threading/channels.nim](https://github.com/nim-lang/threading/blob/f326fd91e4e1976b55ee6f49945288d81ad7403f/threading/channels.nim#L310C1-L310C19). What my `SharedRc` experiment did was to turn `GC_ref` and `GC_unref` into atomic operations by peeking under the hood of ARC/ORC. This would allow sharing a (mutable) ref object between multiple threads. Of course, you'd still have possible data races with the data in the ref object. So `SharedRc` would need to be used for immutable data or used with locking for mutable data. The `mm:atomicArc` flag @Araq mentioned changes ARC to use atomics for every ref count. > I've created a Container object to allow this: > <https://github.com/Alogani/NimGo_multithreadingattempt/blob/main/src/nimgo/private/safecontainer.nim>, > which must be used inside the awesome SharedPtr > (<https://github.com/nim-lang/threading/blob/master/threading/smartptrs.nim>), > without forgetting to use a channel to avoid race condition ;-) You probably don't need that as `Isolate` basically does the heavy lifting. You can always use `unsafeIsolate` if you know the object isn't shared and ownership can be given to the other side.
