[gclist] Destructor FAQ

[Robert A Duff]

Hans_Boehm.PARC@xerox.com writes:

> But that's an artifact of the example.  Probably a more common use of
> finalization is in a wrapper object W for an object T managed by a third-party
> C library.  When all references to W are dropped, W's finalizer calls free(T).
> If the implementor of W isn't careful, you again have a dangling pointer.

Well, OK, in *that* case, you've convinced me.  I was ignoring the
merely practical issue of interfacing to C, and thinking only about the
academic issue of designing a language feature to be part of the
"perfect" language that need not interface to anything else.

> As you suggest, you can avoid the problem with cycles by imposing a
> finalization ordering based on types and not reference patterns.

I admit that I haven't thought much about how to *implement* that --
i.e. how to tell the gc what the order is supposed to be.  The gc has
it's hands on all these pointers, not type decls (at least not
directly).

> Expanding on the file example a bit, consider the case in which the unbuffered
> file is actually a frob, which is implemented by a foo, which has a finalizer.
> As the implementer of the buffered stream abstraction with static finalization
> order, I now need to make sure that I get the right finalization ordering with
> respect to a foo, which is implemented in some other module which I shouldn't
> know about.  If I use topological ordering, the garbage collector will simply
> conclude that the unbuffered file depends on the foo, and finalize the
> unbuffered file first.

You've partly convinced me.  If this argument is correct, then I think
it applies to Ada's rules about finalizing heap objects at end of
program, too.  I.e., I still claim that the issues aren't *purely*
caused by garbage collection.

Maybe we should talk about something else for a while...  ;-) ;-)

- Bob