Workaround for typeid access violation

[Etienne Cimon via Digitalmars-d]

On Wednesday, 17 June 2015 at 22:21:21 UTC, Laeeth Isharc wrote:
> On Wednesday, 17 June 2015 at 21:35:34 UTC, Etienne wrote:
>
>>> I am no compiler/runtime guru, but it sounds like if it were 
>>> possible to make this a swappable option for D this might be 
>>> very important.  Is this true, and how much work is involved 
>>> in making this industrial strength?
>>
>> To me this is 100 times more stable simply because destructors 
>> can no longer be called from any thread. I'm also going to 
>> keep this implementation for its guarantee that destructors 
>> will be called. The absence of locking and stop the world 
>> makes it a very high performance GC.
>>
>> Of course, the tradeoff is the absence of support in moving 
>> objects between threads. That's really an insignificant 
>> limitation compared to the above points. I don't expect it to 
>> be merged simply because nobody is familiar enough with this 
>> type of GC to have a say, except for what a GC shouldn't 
>> guarantee in general. And I'm really tired of people telling 
>> me what I can't or shouldn't do, when I'm brainstorming on 
>> this forum.
>
> Do you have any links to reading material on this type of GC?
>
> I appreciate that it may in the general case be more stable, 
> but in the particular implementation usually there is some 
> distance to go from something good enough for personal use to 
> something that others can depend on without having to 
> understand the nitty gritty of the implementation.  So that is 
> what I was asking...

No reading material. It's straightforward from my train of 
though, your object will be collected if it's not either in the 
immediate global namespace, in the current thread's stack, in the 
current thread's local namespace or in objects that were 
allocated in the current thread's GC.

People saying that this will fail in basic message-passing or 
multi-threading are right. If you move your object in another 
thread's object even though the other thread's object is in the 
global namespace, you can't expect it to be tracked by the 
thread-local GC.

e.g. __gshared MyObj g_obj1;

Thread 1: g_obj1 = new MyObj;
Thread 2: g_obj1.obj2 = new MyObj;
Thread 3: write(g_obj1.obj2); <-- access violation (probably)

That's the "moving objects between threads" limitation I'm 
talking about. You need to use manual memory management and 
containers if you're going to use it for this purpose.