On Thu, 26 Feb 2015 21:56:30 -0500, Steven Schveighoffer wrote: > On 2/26/15 7:34 PM, ketmar wrote: >> On Thu, 26 Feb 2015 18:04:28 -0500, Steven Schveighoffer wrote: >> >>>> That's true. However, what if the destructors access global >>>> (thread-local) variables? Is that already disallowed? >>> >>> Hm... I don't know. Is it "disallowed?" I don't think so (a simple >>> test would suffice), but if any code exists today that does it, it's >>> very very wrong :) I would suspect that such code should be banned. >> >> but what if i'm doing memory managing myself and i *know* that it's ok >> to use thread-locals in my destructor? >> >> > Accessing thread-local data in the GC-run destructor means you are > accessing in the GC collecting thread. In the case where we make dtors > run in the originating thread, it is OK. But if the thread is gone, then > any running of that dtor may incorrectly use the TL data in that thread, > which may not be correct. > > In any case, accessing thread local data today is most certainly wrong, > since there isn't even a likelihood the same thread will destroy the > data. > > I can't see a situation where this would be what you wanted. Accessing > global data should be fine, but thread-local data is not.
let's assume that i have a program that has only one thread. i know it for sure. and i don't like prepending ugly `__gshared` to my declarations. sure, it all depends of GC code (it can be multithreaded itself, or it can deliberately run finalisers in another thread), but why i should not be allowed to do what i want? i can write that GC myself, and i *know* that there will be no other threads. this is the same as allocating in finaliser: as finalisers aren't made implicitly @nogc, i can see no sense in restricting 'em in any other way, as the same arguments applies in both cases.
signature.asc
Description: PGP signature
