Hard-to-reproduce GC bug

[Sean Kelly]

== Quote from dsimcha (dsimcha at yahoo.com)'s article
> == Quote from Sean Kelly (sean at invisibleduck.org)'s article
> > Weird.  The actual storage for TLS in druntime is an array of void*
> > within the Thread class.  I can't imagine that it wouldn't be scanned by
> > the GC.  Do you have a reproducible test case?
> > Sean
> I just now managed to play around with this some more and come up with a small
> test case, as opposed to a much larger real-world case, that reproduces this.  I
> still haven't the slightest clue *why* my latest test case reproduces the bug and
> some others that I had tried didn't, but I've filed a bug report.  See:
> http://d.puremagic.com/issues/show_bug.cgi?id=2491

Oh!  You're using the built-in thread-local storage.  I don't think that's fully
implemented yet (Walter, please correct me if I'm wrong).  You might want to
use the thread-local storage feature in the Thread class for now.  Depending
on your memory / performance requirements:

import core.thread;

void main()
{
    auto t = new ThreadLocal!(int);
    t.val = 5;
    writefln( t.val );
}

-or-

import core.thread;

void main()
{
    auto key = Thread.createLocal();
    Thread.setLocal( key, cast(void*) 5 );
    writefln( cast(int) Thread.getLocal( key ) );
}

the second approach is closer to how C/C++ TLS works and saves
the allocation of a wrapper struct, but is clearly more complicated
in exchange.  your best bet is probably to simply use ThreadLocal
for now, since it will be easier to change later when built-in TLS
works properly.


Sean