[gclist] Finalization, again

[David F. Bacon]

i agree that it doesn't make sense to synchronously invoke a destructor at
whatever arbitrary point you discover that the object has become garbage (since
you might be in a different thread that belonged to a different "user" of the
system).

but i would go a step further.  i would say that the only thing that makes sense
for finalizers is  [giving the appearance of] running each one in its own
thread.  otherwise, there is no way to tell the difference between a finalizer
in an infinite loop and a finalizer that's doing a lot of work, and you wind up
in a situation where one finalizer can cause other finalizers to starve.

the other sensible alternative would be to statically require that finalizer
methods execute no unbounded loops or blocking operations.

david

"Boehm, Hans" wrote:

> Speaking of finalization (which always seem to get the traffic on this list
> back up), there have been some interesting discussions on some of the C++
> lists.
>
> My conclusion (which is not yet :-) universally accepted), is that the goal
> of "deterministic destruction", which is often stated there, is really based
> on a misunderstanding.  Destruction/finalization of heap objects in general
> has to be asynchronous to be correct, even if your garbage collector
> reference-counts.  I put an argument to support this in
>
> http://www.hpl.hp.com/personal/Hans_Boehm/gc/det_destr.html
>
> Hans