[gclist] Destructor FAQ

[boehm.PARC@xerox.com]

"> I would argue that we should distinguish between 2 concepts:
>
> - destructors (a.k.a Ada "finalization")  These are basically actions invoked
> at predefined times when a variable goes out of scope.  These can safely be
> used for all sorts of things, including releasing locks, closing windows,
etc.
>
> - finalization (not Ada "finalization").  These are actions invoked
> asynchronously when the system determines that an object (usually in the
heap)
> can no longer be accessed.  Useful only for non-time-critical resource...

I don't see why you want to make a big deal about this distinction.
Yes, finalization can be used in both ways, but I see no need for two
different language features."

I'm not arguing that these should be distinct language features.  That depends
on other constraints on the language design.  (The Ellis-Detlefs proposal
combines them, and that's a reasonable choice for C++.)  I'm also not arguing
that they are both needed in all language designs.  The case for "destructors"
in a garbage collected language actually doesn't seem very strong to me, and I
would rather not see them at all.  I am arguing that the two notions should be
kept distinct for this discussion, because it would avoid some confusion.  For
examples, I think Charles ia talking is talking mostly about destructors, since
he assumes that timely execution is crucial.

When I talk about finalization ordering issues, I mean finalization in the
above sense.  It's not clear to me that invoking destructors in topological
order is practical.  I am also assuming that finalizers are used only to
reclaim resources and do not have important visible effects, so timing is not
crucial.

"I don't see any harm in letting a finalizer see an
already-finalized object -- if the programmer has cycles, then the
finalizer has to be written to take that into account.  A finalized
object is still in a well-defined state (maybe it has some nil pointers
in it) -- pointing to an already-finalized object is not a disaster like
a dangling pointer is."

As I've said before, I disagree, though we may be exaggerating the importance
of this issue.  In the near term, the most common use for finalization is
likely to be to invoke deallocation functions in code (e.g. third party C
libraries) that uses explicit memory management.  If a garbage collected object
holds the only reference to an explicitly managed object, then the finalizer
for the garbage collected object has to deallocate the explicitly managed
object.  In this case access to a finalized object is exactly a reference
through a dangling pointer.  The same is true if the finalizer deallocates a
shared memory segment or the like.

Hans
Standard disclaimer ...