"Somebody" should implement this paper:
<https://dl.acm.org/doi/pdf/10.1145/3299706.3210569> or maybe this one:
<https://dl.acm.org/doi/pdf/10.1145/3453483.3454060>
FRC is super interesting as it has direct support for Nim's `var x {.cursor.}:
ref T` idea making these memory safe as well 🙂. FRC is patchable with a cycle
collector component which would give us `mm:sharedOrc`. For a concurrent cycle
collector the best blueprint can still be found in
<https://pages.cs.wisc.edu/~cymen/misc/interests/Bacon01Concurrent.pdf>
Our team of core developers does not have time to work on any of this, but the
algorithms can be implemented in Nim "userland" code via custom hooks on top of
Nim's unsafe `ptr T` construct.
Once a library solution reached maturity, we can port the solution to Nim's
core giving us `mm:sharedOrc`. We should elaborate in the spec that `ref` can
have "delayed" semantics. In other words ref destructors can be scheduled
"later". This solves many problems at the same time. Recursive destructors that
overflow the stack are effectively prevented, performance improves, and in the
real world nobody has a linked list of File objects that need deterministic
destruction. Deterministic destruction is awesome for seq which can be large
and for File/Channel/Sockets but for ref it's neither necessary nor desirable.
YMMV, of course.
