The Revenge of Finalizers

[Simon Marlow]

> > However even if Haskell finalizers + MVars are impossible in NHC, I
> > don't think Haskell finalizers + mutable state have to be.  For
> > example another mutable variable we could have would be a PVar which
> > is always full and has functions [snip]
> 
> > updatePVar (PVar ioRef) updateFn =
> >    do
> >       [stop any new finalizers running]
> >       a <- readIORef ioRef
> >       writeIORef (updateFn a)
> >       [reenable finalizers]
> >       return a
> 
> Just for the record, I think that if we were to pursue this approach,
> then the right primitive to add is:
> 
>   -- |
>   -- Execute argument atomically with respect to finalizers.
>   -- Nested calls to blockFinalizers are allowed.
>   --
>   -- That is, while executing the argument, no finalizers will start
>   -- to execute.
>   -- (Finalizers that are already executing may continue to execute.)
>   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.

Cheers,
	Simon