[gclist] Finalization and death notices

[David Chase]

At 03:10 PM 10/6/2001 -0600, Greg Colvin wrote:
>>|| 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.

>What I don't understand is why "an identifer associated with the object
>not the object's address."  Of what use is the identifier if you can't
>the object's address from it?

There's two answers to your question:

"Why", is that by not handing you the object's address, the object
won't get resurrected.  Annoying problems are avoided.

"What use", if I understand these things right, is that you sort of
turn your data structure inside out.  In terms of users and
implementers of an interface, the implementer hands out the object
that eventually becomes unreachable, but keeps a handle on the
weak reference for the object.  The object handed out may contain
(as internal state) on a pointer to its weak reference -- that's
where all the interesting state is.

So, from the implementation side of the interface, the only use
for the object is to act as a means for detecting if the user
is truly through with it.  When that happens, the death notice
arrives (the weak reference is queued) and the processing of
the weak reference off the queue cleans it all up.

That, at least, is my understanding of how they could be used.



David Chase
chase@naturalbridge.com
drchase@alumni.rice.edu
chase@world.std.com