addForeignPtrFinalizer

Alastair Reid alastair at reid-consulting-uk.ltd.uk
Wed Sep 25 07:49:17 EDT 2002


> However, to provide a general ordering property on finalizers would
> be quite awkward in GHC - I just can't think of an easy way to do
> it.  [Awkward ways deleted]

If I understand correctly, the problem is that each FP has a cloud of
finalizer objects attached to it with no particular structure between
finalizer objects and the reason for this unstructured cloud is because
you're piggy-backing on some other mechanism.

It seems like the easy way to fix this is not to impose structure on
the cloud but to impose structure on the finalizer objects.  That is,
allow finalizer objects to contain a list of finalizers and then
allocate just one.

Sketch of possible implementation:

  // Some useful support code - nothing exciting

  type Finalizer a = FunPtr (Ptr a -> IO ())
  foreign import "dynamic" invoke_finalizer :: Finalizer -> IO ()

  finalize :: IORef [Finalizer a] -> IO ()
  finalize fs_ref = do
    fs <- readIORef fs_ref
    mapM_ invoke_finalizer fs
    

  // New implementation built on top of the old implementation

  data NewFP a = NFP (ForeignPtr a) (IORef [Finalizer a])

  newFP :: Ptr a -> Finalizer a -> IO (NewFP a)
  newFP p f = do
    x <- newForeignPtr p (finalize fs_ref)   // old version with Haskell finalizers
    fs_ref <- newIORef [f]
    return (NFP x fs_ref)

  addFPFinalizer :: NewFP a -> Finalizer a -> IO ()
  addFPFinalizer (NFP x fs_ref) f = do
    fs <- readIORef fs_ref
    writeIORef fs_ref (f:fs)

--
Alastair



More information about the FFI mailing list