[gclist] Finalization, again

[Boehm, Hans]

Cahrles wrote:
> Sure means if you build a finalizer object the finalizer gets 
> run if only
> at end of job.
As I think Charles pointed out, this sort of certainty is highly undesirable
(i.e. broken) if it's enforced for a standard finalizer.  It would mean that
finalizer is run at a time at which objects referenced by globals may
already have been finalized.  That makes it nearly impossible to write
correct and nontrivial finalizers.  (It would also mean that processes could
take arbitrarily long to shut down.  But we already have that problem with a
lot of C++ code.) 

I personally don't think this is a big deal.  If there are OS resources that
really need to be explicitly released by process exit, keep a record of the
ones that are still in use, and explicitly release them with an
"atexit"-like procedure.  In general it seems to be worth a fair amount of
trouble to design OS interfaces etc. to minimize the need for this, since it
means that crashed applications leak resources.

> Also unthreaded systems are more efficient than threaded ones. Saying
> threads are required by finalizers is unacceptable. If the 
> user doesn't use
> threads the finalizer system can't run out and use them.
> 
You can fake it with explicit queues.  It's not as clean.  But neither are
the other mechanisms we commonly use to eliminate or reduce the number of
threads in order to improve performance.

Hans