On 19.11.2014 21:08, Steven Schveighoffer wrote:
On 11/19/14 3:46 AM, Daniel Murphy wrote:
"Rainer Schuetze" wrote in message news:[email protected]...
I remember having an invariant on a tree structure checking
consistency by verifying the children and parent references. This
crashed when adding a destructor. With the proposed change it will
always crash.
The problem is that the destructors of the tree nodes are called in
arbitrary order when they are collected by the GC. Class instances are
also made invalid after calling the destructor (the vtbl is zeroed).
I wonder if
- such invariants are invalid,
- the GC should bypass the invariant when calling the destructor
- or we should never call the invariant with the destructor?
I think the 'correct' solution is to check the invariants before any of
the parts are destroyed.
This may sound feasible, but it rules out some GC algorithms, as the GC
may free things and destroy them in pieces, and not worry about the
reachability. I don't think we should provide any guarantees about
destructors being able to access GC data.
We really *REALLY* need a mechanism to determine whether destruction is
happening in a GC or not. In synchronous destruction (i.e. destroy or
scoped), you can run the invariant. In GC, you cannot.
That would be quite within reach for classes with the current GC if the
compiler would not generate the invariant into the destructor at all,
but leave it up to to _d_delclass to call it. The GC uses rt_finalize2
to destroy collected objects and skip the invariant.
A similar mechanism is possible for structs, but
- the invariant needs to be added to the type info
- the compiler needs to generate code to call both the invariant and the
destructor, or delegate this to a callback in the runtime
