Destroying structs (literally)

[Orvid King via Digitalmars-d]

On 8/30/2014 10:35 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= 
<schuetzm at gmx.net>" wrote:
>
> The problem is not only dereferencing those pointers (though depending
> on how the GC works even this might be racy, i.e. the memory location
> could have been reused already), but that a destructor/finalizer already
> ran on the referenced object. It is thus potentially in an invalid
> state. Even copying it is dangerous, because you're then creating a live
> object from that invalid state which will itself be destroyed again at
> some point. This might lead to double frees of depending manually
> allocated objects, or potentially other problems. Then there's the
> possibility to "resurrect" such an object by storing a reference to it
> somewhere else during finalization.
>
> Doing the scanning and finalization separately like this is _probably_
> safe:
>
> 1. Marking phase as usual.
> 2. Select the objects that have a finalizer, and clear all references in
> them that point to objects that are now unreachable. (This requires a
> precise GC.)
> 3. Call the finalizers.
>
> Not sure what to do about things that may or may not be references.

It's perfectly fine to not be able to guarantee the order of the 
finalization, but we can guarantee that the values referenced by the 
allocation being finalized are still allocated. It's up to the user to 
understand that the finalizable object they are trying to reference in 
their destructor may already have been finalized.