[gclist] Finalization and death notices

[Charles Fiterman]

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())
     ...
   else
     ...
}

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