[gclist] Finalization and the insane postman bug.

[Boehm, Hans]

> -----Original Message-----
> From: Charles Fiterman [mailto:cef@geodesic.com]
> So what is required is a death notice. The user 
> is informed
> by some mechanism that an object died. The death notice is an 
> identifer
> associated with the objct not the object's address. Now 
> priority, order,
> time and context are in the user's control. If some objects 
> are reference
> counted they give death notices too.
> 
> At no point do objects rise from the dead to alter the bits 
> of the living.
> That's a bug the collector promices objects will be deleted 
> when they can
> no longer influence the order of execution. Finalizers alter 
> the order of
> execution.
> 
I think it actually doesn't make much of a difference. 

Let's say you want to be notified of object A's unreachability.  The
language provides for finalization, but you would rather see this sort of
"death notice" delivered to B.  No problem.  Simply add a pointer from A to
B and make B finalizable instead.

You can also almost go the other way.  If you want a finalizer for A, but
the language gives you some form of "death notice", you move all the
interesting data that was in A into a separate object C referenced from A,
and you also give the object to be notified of the death a reference to C.

I think neither model either solves or creates any significant problems
relative to the other.  In either case the collector communicates
reachability information back to the user, and that's all it does.  A
finalizable object doesn't rise from the dead; a finalizable object is
refrenced by a data structure private to the collector; it is notified when
it's reachable only from that data structure.

Hans