[gclist] Finalization and death notices

Charles Fiterman cef@geodesic.com
Wed, 10 Oct 2001 09:59:56 -0500

I think a necessary difference between death notices and near death notices
is that while you can have many death notices there should only be one near
death notice.

A death notice informs an interested party of the death of an object and
there may be many interested parties. Indeed if there was a data structure
for news a death notice could be published in the news. This may be common
practice for some large programs.

A near death notice informs a registered custodian that they are the only
one with a remaining interest in an object and they now hold the last
remaining thread keeping it alive. You can't have two of those. If a second
one registers they need to be informed of the conflict and the actual owner
so they can work it out.


Consider the following potential bug. The user builds a locker object which
locks a given resource in its constructor and unlocks it in its destructor.
The idea is to build a locker on entry to a control block and automatically
unlock it on exit. Thus exceptions etc. cannot bypass the unlock.

All this seems very good and is surly an improvment over normal coding
practice. But

   locker x(foo.lock);

   if (fork())

How do we implement locker objects with current C++ destructors? What about
our death notice & near death notice. Assume its important to unlock promptly.