The Revenge of Finalizers
simonmar at microsoft.com
Mon Oct 14 07:21:22 EDT 2002
> > 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.
More information about the FFI