[gclist] Destructor FAQ

[fjh@cs.mu.OZ.AU]

Robert A Duff, you wrote:
> 
> Also, I don't really understand the distinction you're making.

I think the important distinction is between synchronous finalizers
(which Hans Boehm calls destructors) and asynchronous finalizers (which
Hans calls finalizers).

> I only
> see one feature, call it what you want.  Heap-based objects have a bit
> looser definition of when things happen, so what?  Integers on the heap
> have a less well-defined lifetime than integers on the stack.

The definition of when heap-based objects die in a language without GC
is no less strict than the definition of when stack objects die.
In such a language, stack objects die when their containing procedure
exits, and heap objects die when they are explicitly deallocated.

However, in a language with GC, it is unspecified exactly when the
finalizers for heap objects will be called.  Ideally the finalizer
should be called "as soon as the object becomes unreachable", but
this is not feasible, and so in practice the finalizer gets called
a some unspecified point after that, e.g. at the next garbage collection.

There is a significant different between synchronous finalizers, which
will be called at points clearly specified by the language, and
asyncronous finalizers, which might be called anytime between when
the object becomes unreachable and when the program exits (or might not
even be called at all).  For one thing, the user needs to be a lot more
careful how they write asynchronous finalizers.

> > ...I've never missed them [synchronous finalizers] in a garbage
> > collected language.  Since they occur at well-defined points, they are
> > essentially syntactic sugar for a procedure call I could make
> > explicitly.
>
> Not easily.  That is, not without breaking abstractions.

I tend to agree with Hans -- I've never missed them.
If a finalizer is only deallocating some resource, you can just make
it an asynchronous finalizer.  If a finalizer has some visible
side-effect, then that side-effect should be a part of the interface
to that object -- in which case the finalizer is just syntactic sugar
for a procedure call.

Could you explain in a bit more detail why you think synchronous
finalizers are necessary to avoid breaking abstractions?

-- 
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3
"No Bad Religion song can make your life complete" -- Bad Religion.