[gclist] Finalization and death notices

[Kerns, Bob]

You look up the identifier in a hash table or similar structure, to obtain
the data needed to do the cleanup.

For example, this could be a low-level file descriptor that needs to be
closed.

However, while working with an identifier rather than the object solves many
issues with finalization, I don't see that it addresses the thread issue. I
think we have to look at this as two separate ideas.

I think what addresses the thread issue is hidden away in the phrase "an
event posted by the system to the user program". This is an implementation
choice that could equally be applied to finalization, assuming I understand
what you mean by it. This event notification style is what avoids the
threading issues, while the use of an identifier to a death handler is what
avoids the problems with object revivification and such.

-----Original Message-----
From: Greg Colvin [mailto:gcolvin@us.oracle.com]
Sent: Saturday, October 06, 2001 2:11 PM
To: gclist@lists.iecc.com
Subject: Re: [gclist] Finalization and death notices


From: Marc Shapiro -- at work <marc.shapiro@acm.org>
> || Date: Thu, 04 Oct 2001 14:57:45 -0500
>  || From: Charles Fiterman <cef@geodesic.com>
>  || Subject: Finalization and the insane postman bug.
>  || 
>  || 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.
> 
> I have been following this argument from afar.  Clearly there is a need
> for some application-level cleanup mechanism when certain objects are
> collected, but finalisers are very bug-prone.
> 
> I think I'm convinced now that finalisers are bad and death notices are
> good.  A death notice is just an event posted by the system to the user
> program.  It's up to the application code to pick it up at leisure.  So
> it's the user's responsibility to fork threads or not, catch exceptions
> or not, and to worry about termination or not.  The user gets the
> service he needs, and the system does not get compromised.

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 objexcts address from it?