On Thursday, 10 July 2014 at 16:20:43 UTC, Sean Kelly wrote:
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.
https://github.com/D-Programming-Language/druntime/pull/493
Given the changes, it may be worth rejecting the pull request
above and creating a new one for this approach, but this is the
history anyway.
