The Revenge of Finalizers
alastair at reid-consulting-uk.ltd.uk
Sat Oct 12 12:50:07 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 =
> [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
[The last sentence is to take care of cases like finalizers calling
One would then write George's example like this:
> updatePVar (PVar ioRef) updateFn = blockFinalizers $ modIOVar ioRef updateFn
This is what I was referring to the other day when I suggested that a
mechanism in the style of interrupt disable might be easier to
implement than MVars.
More information about the FFI