GC, the simple solution

Frank Benoit keinfarbton at nospam.xyz
Sun Jun 4 07:41:20 PDT 2006


> As I've understood from Boehm's paper, one advantages of a GC is to fix this 
> issue: a GC collect will call finalizers for the objects that were created 
> in that thread. It's like keeping an object from being destructed until the 
> thread that created the object calls malloc 

This is not true for the phobos GC. The GC runs in the thread which
calls new or gc.fullCollect.
But the Dtors are not called while other threads are running, because
the GC pauses all other threads. This is called the "Stop-the-world".


> I meant my example like this: object A has a reference to object B. During 
> the destruction of A, the references it has to other objects are released, 
> causing some objects being destructed, like B. Now B might (indirectly) use 
> data from A, but A's in the middle of destruction. What I mean to tell with 
> all this is that you still have to be carefull with your destructors. 
> Especially when using a strong-pointer template. You can't always tell what 
> state other objects are in in a destructor. They might be half way during 
> destruction, having released some, but not all, of their references.
> 

Object A cannot be destroyed, if it is reachable directly or indirectly.
That is, the ref counting is for. So if A.~this() is called, nobody else
has a reference to A.



More information about the Digitalmars-d mailing list