Thread-local GC?

[Sean Kelly via Digitalmars-d]

On Thursday, 10 July 2014 at 02:51:05 UTC, logicchains wrote:
> I was wondering if thread-local GC had been considered an 
> option for making D's GC work better in threaded code? Erlang 
> has this (well, process-local GC, which is closer to 
> fibre-local in D terms) and it seems to work okay, although I 
> don't think Erlang allows shared memory between processes.
>
> If this were possible, it would be particularly useful if it 
> could be combined with nogc to allow the spawning of nogc 
> threads. These could be used for latency-sensitive work, with 
> the guarantee that work done in a nogc thread would never be 
> paused by garbage collection done in other threads.

I really like this idea.  It would neatly address my issues with 
a long-standing pull request for adding provisions to core.thread 
for creating threads that should not be blocked by the GC on 
collections.  Just add detection in the Thread ctors for the 
@nogc label and set the appropriate internal flag.

It's still kind of a veneer over potentially risky code, since 
@nogc code can manipulate references to data in the GC and so be 
the sole owner of data that will then vanish on the next 
collection, but it seems a good way to document what's desired 
and enforce some degree of correctness.