Re: Hiding the effect of concurrent finalization

* Hans Boehm:

> The standard solution for single-thread environments seems to be to
> put ready-to-be-run finalizers into a queue, and then require the
> user to explicitly take some action to run those, ideally when
> nothing else is going on, and none of the data structures updated by
> finalizers are currently being updated by the mainline code.

Oh.  This is fine if you've got some sort of event loop.  Without
that, it's a bit tricky.

> My (unproven) intuition is that running finalizers for T when a T is
> being allocated is relatively likely to run finalizers when the
> underlying data structures are already in use, and thus perhaps more
> likely to break things than running them in response to a random
> allocation.

I would combine this with the queue approach.  That is, the
constructor for some type T would be responsible for dealing with
objects of type T pending finalization.  The assumption is that
constructing a T has some sort of visible effect, and destructing
another T probably has a similar effect, so one should be okay when
the other is.  (If not, T's constructor can delay finalization
further, but I expect that to be rare.)

> Is it possible to run into the same kind of premature finalization
> issues described in my 2003 POPL paper?

Do you mean the effects of impreciseness in the definition of
reachability?

I think this is of less concern in my case because regular use will
involve synchronous cleanup, which introduces a reference at the end
of the scope in which the object is regularly used.  (I can probably
make the spec quite tight, too.)