On Thursday, 17 April 2014 at 18:26:25 UTC, Dicebot wrote:
I think for your scenario having dedicated @nogc threads makes more sense, this can be built on top of plain function attribute @nogc.
Yes, that could be a life saver. Nothing is more annoying than random crashes due to concurrency issues because something "slipped in".
But I think both you and Bearophile are right in pointing out that it needs more thinking through. Especially the distinction between calling into GC code and dealing with GC memory.
For instance, maybe it is possible to have a memory pool split in two, so that the no-GC thread can allocate during a collection cycle, but be required to have a lock-free book-keeping system for all GC memory referenced from the no-GC thread. That way you might be able to use GC allocation from the no-GC thread.
Maybe that is a reasonable trade-off. (I haven't thought this through, it just occurred to me) Ola.
