@Araq: > As I said "araqsgc" is a hybrid, it will work with async too.
I can see how "araqgc" is intended to be a hybrid; **what I fail to see in the code or in testing is how to make the ``traverseObjHook`` fire** so I can test it without calling dispose, deepDispose, or `collect`, which would be the other manual part of the "hybrid". But also, being a hybrid, **it also has all the disadvantages of mark-and-sweep GC 's in nondeterministic destruction, execution overheads, etc**., even if the overheads have been reduced in this simplification. > However, to me it's an open question of whether `async` intrinsically really > needs it (atomic ref counting) or the current `async` implementations need it > or neither... I haven't looked at the code for `async` yet; guess it's time I did. Maybe its good that I am coming from outside the dev team, as all of you have been buried in the current implementations and problems for so many years that maybe there is something else that is so simple that it has been missed: I've got something cooking that I think might be possible within the current general code base framework that should be compatible with owned although having owned shouldn't be necessary to make it work based on how clever the current Nim compiler is at managing data flow analysis built around the AST; another good thing about it is that it isn't a tracing GC, but I think it should be able to support some implementation of `async`. Give me a few hours to let it stew and to try to test some of the ideas within the current version (now up to version 1.0.2 I see - unannounced?) and I'll present it here for your opinion. I may not be able to easily test it within the current code as I need to be able to use some sort of "hooks" to tie into the handling of `ref`'s, so I may need to emulate that with some use of destructors plus some manual code.
