The Revenge of Finalizers

[John Meacham]

I was thinking that blockFinalizers would not be exported, but rather
used to implement whatever Mutable State standard with 'potential
concurrency' is proposed. PVars, subset of MVars, atomic IORefs or
whatnot, and in the implemententaion of the standard library to make
sure it is finalizer-safe.
	John

On Mon, Oct 14, 2002 at 10:38:55PM +0100, Alastair Reid wrote:
> 
> >> blockFinalizers :: IO a -> IO a
> 
> > Indeed, I very nearly implemented such a thing as part of the patch
> > I sent out.  However, it didn't look trivial enough to implement so
> > I backed off.  The "blocked" state needs to be saved & restored at
> > various points: when starting a finalizer, when invoking a
> > foreign-exported function, and when invoking an exception handler.
> 
> I think it's fairly easy.  A sketch is something like:
>   
>   // primitive called from Haskell
>   void blockFinalizer(Cell m, State world) {
>     blocked += 1;
>     eval(ap(m,world));
>     blocked -= 1;
>     runFinalizers();
>   }
>   
>   // function called from garbage collector when a dead foreign ptr is found
>   void scheduleFinalizer(Finalizer f) {
>     pending = cons(f,pending);
>   }
> 
>   // function called when GC and blockFinalizer finishes
>   void runFinalizers(void) {
>     if (blocked == 0) {
>       while (nonEmpty(pending)) {
>         Finalizer f = head(pending);
>         pending = tail(pending);
>         eval(ap(f,world));
>       }
>     }
>   }
> 
> There's a few details to take care of (e.g., avoiding calling cons in
> scheduleFinalizer) but they're all manageable.
> 
> 
> I think Malcolm and I can probably make this work for NHC and Hugs
> without too much work.  (Malcolm: feel free to disagree.)
> 
> I think there are some difficult, unexplored issues about the
> usability of this primitive.  e.g., since GHC already has MVars, when
> do you use blockFinalizer, when do you use MVars and when do you use
> both?  How do you write code that works on GHC, Hugs and NHC?  For
> this reason, I'm not sure this is a good design and my preferences
> are:
> 
> Best: C finalizers subject to same restrictions as unsafe foreign imports.
>       (Straightforward)
> 
> Moderate: Haskell finalizers plus blockFinalizers.
>          (May be awkward to use in portable manner?)
> 
> Poor: Haskell finalizers that may access Haskell state
>       (Needlessly complex)
> 
> Worst: Haskell finalizers that may not access Haskell state
>        (Introduces many problems without giving any benefits)
> 
> --
> Alastair
> _______________________________________________
> FFI mailing list
> FFI at haskell.org
> http://www.haskell.org/mailman/listinfo/ffi

-- 
---------------------------------------------------------------------------
John Meacham - California Institute of Technology, Alum. - john at foo.net
---------------------------------------------------------------------------