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.
