Destructor/Finalizer Guarantees
Algo via Digitalmars-d-learn
digitalmars-d-learn at puremagic.com
Tue Nov 11 20:06:09 PST 2014
On Tuesday, 11 November 2014 at 22:31:17 UTC, Maxime
Chevalier-Boisvert wrote:
> I have a situation where I have a VM (virtual machine) object,
> and several GCRoot (garbage collector root objects). The
> GCRoots are structs and will "register" themselves into a
> linked list belonging to the VM. I've made it so they
> unregister themselves in their destructor. This works perfectly
> well for GC roots which are on the stack.
>
> However, recently, I ran into a case where I need GCRoots which
> are not on the stack. This is where things broke down. The VM
> object got destroyed before the GCRoots, and when these tried
> to unregister themselves, they accessed memory which had
> already been reclaimed (the dead VM). What I want to know is:
> what guarantees can I expect from destructor behavior?
>
> I was thinking that when the VM gets destroyed, it could
> unregister all of its GCRoots at once. Then, when these are
> destroyed, they wouldn't try to touch the VM object. However,
> this only works if I can assume that the GC will first call the
> destructor on an object, then free the object, that this is
> done in a predictable order. Am I on the right track, or do I
> need to rethink this?
Could this work?
class VM {
List gcRootList;
this() {
gcRootList.add(GCRoot.init);
..
to
class VM {
static List[VM*] _gcRootLists;
List* gcRootList;
this() {
_gcRootLists[&this] = List.init;
gcRootList = &_gcRootLists[&this];
gcRootList.add(GCRoot.init);
..
~this() {
_gcRootLists.remove(&this);
..
More information about the Digitalmars-d-learn
mailing list