@Araq: > It's important to see the full picture, most of what Nim's `async` does is > probably simply hidden from your view as F# delegates the hard work to C#'s > event loop implementation whereas in Nim there is little in between `async` > and the underlying event loop. IMHO that's why you think is "bulky".
**You are probably right** ; although I have looked at how F#'s computational expressions are implemented (investigating why `seq`/enumerations are so slow), I've never looked under the covers at the DotNet code used to actually implement what it uses, though that is now open source and available in DotNet.Core. I do know that F# calls into DotNet's thread pool dispatcher when it needs to use threads for any sort of multi-threading and where threading is required for `async`/`await`, so it isn't so much calling into C# facilities as just the general facilities available in DotNet. **As stated, it 's beside the point of the problem** of implementing either a GC that can support Nim's `async` in whatever it does or making it possible to use "newruntime" to do it. As you say, any working tracing shared-memory GC such as Boehm, Go, or your new "araqsgc" can be made to do the job. **My point is that it doesn 't look to be too hard to make the "newruntime" support a hybrid of reference counting and B/D to also do the job** without requiring changes to the current `async`. **My idea of reasonably easily adding a combination of the different concepts to "newruntime" would seem to make it work.** It combines the currently almost working `owned ref`'s with reference counting where multiple ownership of the same data is required (especially in multi-threading) and with `deepDestroy`/`deepDispose` that I think may be able to accommodate cyclic data if desired so as to seemingly fill the bill. I've now backed off as trying to do this through "\--gc:destructors" hooks and now think that these ideas would just be part of "newruntime" **with the main extra requirement that there would be a little bit of extra code required to handle the two levels of destruction as in B /D and the shared-memory reference count**. I've backed off of tying into the old `threadpool` type `deepCopy` which has already been removed for "newruntime"; my point there is that one would inject the shared-memory ref counted copies at the same place where these `deepCopy`'s used to be injected, but that they shouldn't need to have all the "compiler magic and cruft" with the new destructor based versions of `seq`'s/`string`'s (and closures?), perhaps with the currently forbidden copy of an `owned ref` becoming possible through reference counting. You've mentioned adding some extra fields such as task ID's to `async` to make it work with "newruntime"; my ideas here are to try to make "newruntime" work so that changes aren't required to `async` to be able to work so that the accommodations would be made in one place. **My thinking is that if field(s) need to be added** to `async` tasks that likely need to be atomic in order to make it work with "newruntime", **it would be better to first investigate just adding atomic ref counting to B /D in "newruntime"** in such a way so that it would be used about as often as those extra task fields in order to narrow and thus simplify the things that need to be changed and tested. **I am trying to think of a way to easily test my ideas in the current code base** as by dropping back to using "newruntime" would seem to eliminate the requirement for "compiler magic" that isn't already there and would only require changes within the handing of `owned ref`. The primary areas that need to be tested is how the "big three" of `seq`'s, `string`'s, and closures environments as well as `ref`'s cross the shared memory barrier. You have mentioned back-porting `deepDispose` and `dispose` across all the memory management so that part will have to be done anyway. **You 've mentioned a "race" between "araqsgc" and "newruntime"** and whichever supports `async` first wins. Although I see that the mi-malloc allocator may be a desirable facility to have available as an option in Nim, I see that "araqsgc" is just another mark and sweep GC and **I would really like to see "newruntime" win, as it is unique and more elegant.**
