The Revenge of Finalizers

Alastair Reid 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 =
>    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

[The last sentence is to take care of cases like finalizers calling
blockFinalizers.]

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.


--
Alastair



More information about the FFI mailing list