@Araq: > Ok, now what are the differences? How does "araqsgc" work? Will tell you > later, I have to go now.
I've been checking this thread for answers for the past two weeks since this post appeared and there haven't been any, so I have researched [your "araqsgc" project](https://github.com/Araq/araqsgc) to find the following (part of what I think I found [is posted in the "types of gc" thread](https://forum.nim-lang.org/t/5232#33671)): 1. As per that thread, the "\--gc:destructors" compiler option is intended so that custom implementations of memory management/garbage collection/allocators can be "hooked" in using the available (but undocumented) newObjHook and traverseObjHook. 2. Currently, use of the above compiler option also turns on new seq/string semantics (which also apply to the "newruntime" option where this is automatically turned on) making their use more efficient; now, in the "devel" branch there is a separated "\--seqsv2" compiler option (automatically turned on for "newruntime") which can be optionally enabled (for any of the gc modes?) to see these improved destructor semantics enabled without forcing one to use "\--gc: destructors" (or "newruntime"). 3. As to what "araqsgc" is, it is a simple garbage collector built around the "mi-malloc" allocator [developed by Daan Leijen, et al, of Microsoft Research](https://www.microsoft.com/en-us/research/publication/mimalloc-free-list-sharding-in-action/) and available to the open source community under the same MIT license that Nim uses. Its [technical merits are described here](https://microsoft.github.io/mimalloc/) (with links to performance measurements), and [the actual repo is here](https://github.com/microsoft/mimalloc). your "araqsgc" project is a simple Nim wrapper around this implementation that uses the parts of it as appropriate and hooks it all into the above mentioned "gc hooks". The "newruntime" has been discussed at length in other forum threads, and currently partially works inside the current Nim version 1.0 and the "devel" branch, with promises that work will continue and that it won't be dropped. The main limitation with the current state of "newruntime" is that is still doesn't smoothly work with multi-threading and the current multi-threading libraries (which was supposed to be one of its features/advantages), but it does look to be possible to make it work. Paraphrasing what you have said, you have pulled back a little from the "newruntime" implementation in favor of this new GC implementation due to the changes required to existing libraries to support the "newruntime", not only limited to the required addition of the owned ref keyword and other supporting programming constructs in order to make it work with those libraries. The "araqsgc" project seems to be a "drop-in" solution to the problems of multi-threading without requiring library changes, requiring only that the araqsgc library be imported and that the "\--gc:destructors" compiler flag be used. To those reading this post: Both of these sub-projects show that @Araq continues to do the research to look for better solutions for the current "state-of-Nim" with the "newruntime" the result of his reading a paper by Bacon/Dingle describing the use of the owned ref idea and this latest version of a multi-threaded GC from his reading of the Microsoft paper describing the "mi-malloc" project. Hopefully, one of these solutions will make the use of multi-threading in Nim much easier, which is one of Nim version 1.0's main (and most difficult to work around) weaknesses...
