[MLton-devel] finalization

[Stephen Weeks]

> More importantly, if I have some code which needs to be sure that
> no  finalizers  run during it, I don't have a way to delay them.  I.e., given
> any finalization mechanism, in some other code I might want to  do  something
> like
> 
>     withoutFinalizers
>        (fn () =>
>            (...))
> 
> which  runs  the  thunk, but if a GC happens while it is running, the afterGC
> thing doesn't run until after the thunk finishes.   It  then  runs,  and  the
> result of this expression is the result of the the thunk.

With what I just checked in, finalizers are like any other signal
handler, and can be prevented by using a critical section
(MLton.Thread.atomic{Begin,End}).

> My argument is just that one needs to have a global agreement on how
> to delay the afterGC thing, what context the finalizers are run in
> (signals blocked, etc.), and I don't see an obvious set of such
> things to pick.

Agreed.  Treating finalizers like signal handlers was the simplest
thing to do from an implementation point of view.  So, for now,
signals are blocked during finalization, as with any other signal
handler.


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel