== Quote from dsimcha ([EMAIL PROTECTED])'s article > == Quote from Sean Kelly ([EMAIL PROTECTED])'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