Finalizers: conclusion?

[Simon Marlow]

> I also need the touchForeignPtr trick in much of my code. we need to
> come up with a replacement if we dont have haskell 
> finalizers. here are my canidate suggestions:
> 
> * add a subset of Weak pointers (or some subset of their 
> functionality)
>   to the FFI spec. just get rid of the finalizer capability 
> (for obvious
>   reasons) and the Weak pointers work just as well, and it 
> might have uses
>   elsewhere? 
> 
> - or -
> 
> * add addForeignDependency :: ForeignPtr a -> ForeignPtr b -> IO ()
>  (which on ghc is trivially implemented as 
>   'addForeignDependency a b = mkWeak a b Nothing >> return ()')

I'm not sure this does what you want.  It prevents b's finalizer from
being started before a's, but there's nothing that makes them actually
run in the desired order.  The two finalizers can also be started at the
same time, if both a and b are found to be unreachable in a given GC.

It *may* be possible to change the semantics of Weak pointers in GHC so
that a finalizer is considered a strong root, with the finalizer being
passed the key as an argument when it runs.  I haven't fully thought
through the consequences of this though.  In any case, doing it this way
isn't ideal either, because it would take multiple full GCs to work out
all the dependencies.  

Maybe you want to synchronise between finalizers using MVars, but of
course that only works on GHC, and it might not always be convenient.
eg.

	m <- newEmptyMVar
	addForeignPtrFinalizer a (putMVar m ())
	b <- newForeignPtr p (takeMVar m >> ...)

enforces a strict ordering between 'a' and 'b'.

A simpler way in some cases is to use addForeignPtrFinalizer directly.
If you know that you're creating an object 'a' which should be finalized
after some other object 'b', then instead of placing a finalizer on
object 'a', place it on object 'b' using addForeignPtrFinalizer.  We're
going to guarantee ordering between finalizers registered using
addForeignPtrFinalizer.  This doesn't work if 'a' is possibly referenced
from elsewhere, of course.

Cheers,
	Simon