4 ms·

The reference counter with "destructors and move semantics..." is not presently the default, though it will be in the future. The OP mentions that. The current

The reference counter with "destructors and move semantics..." is not presently the default, though it will be in the future. The OP mentions that. The current default GC involves a somewhat unusual memory model that can make certain kinds of multi-threaded programming difficult: each thread has its own heap and independent GC; memory subject to GC cannot be read/written across threads and locks can't be used to remedy the situation; if you force the compiler to accept code that violates the "no shared" rule, the ref count of the GC on one thread or another will eventually get corrupted and the program will crash with SIGSEGV. However, by allocating on and copying to/from the shared heap (which is never subject to garbage collection) you can do message passing across threads.

kaba0 5y ago
I think Erlang has something similar.
elcritch 5y ago
Note I’m using Nim with the new GC (both ARC & ORC) on dual core esp32’s. Locks do work with ARC, though some care needs to be taken. Both the Nim and free-rtos multi-threaded queues work well with the correct move/sink annotations. The design of ARC allows you to move entire memory graphs between separate heaps. It works fine, but what’s not working is the compile time verification that a given memory graph is only owned/aliased by the top pointer. So there’s a lot of work to do in making it “safer and easy” to use. Here’s an example: https://github.com/elcritch/nesper/blob/f54fff8b240e94684ae8ce0ffe2485cfd425497c/src/nesper/servers/rpc/rpcsocket_queue_mpack.nim#L71 https://github.com/elcritch/nesper/blob/f54fff8b240e94684ae8...