[gclist] Finalization and death notices

[Greg Colvin]

From: Boehm, Hans <hans_boehm@hp.com>
> 
> > From: Greg Colvin
> > It wouldn't bother me if optaining locks in
> > cleanup functions were also unsafe.  Different restrictions might
> > be appropriate in other languages, but the idea that the only thing
> > a cleanup function should do is release resources seems appropriate
> > to me.
> The problem is that releasing resources often involves putting them back
> into a global pool for reallocation.  If the pool is maintained inside the
> user program, that generally requires a lock.  (If it's a kernel resource,
> the issues doesn't arise, since the lock can't be acquired by user code.)

Ultimately, it seems, all resources are kernel resources.

> > The death notice idea has it's attractions as well, as it makes
> > possible the promise that garbage collecting the memory of a
> > correct C++ program will not break the program.
> How so?  You are still running arbitrary user code which wouldn't otherwise
> be run.

That is, if you ignore the notices.  If you decide not to
ignore them ...

This seems to come back to the same old debate about GC for
C++ -- to finalize or not to finalize, and if so how?  We
go round and round looking for the "right" way, whereas java
just went ahead and did it wrong, and users soon learned
that finalizers were nearly useless.  And lacking destructors
they learned to manage resources with finally clauses.