ForeignDependencies: The Semantics

[Simon Marlow]

> ack! no with my intended semantics, cycles are not a problem anymore
> than they are for weak pointers or the touchForeignPtr method.
> everything will still be GCed just like normal. 
> 
> (note that these are pretty much exactly the Weak Pointer 
> semantics, if
> you like replace 'ForeignDependency' with Weak Pointer as you read and
> it should make sense)
> 
> addForeignDependency k v   creates a weak pointer from k to v. a weak
> pointer ONLY affects GCing and guarantees __nothing about the 
> ordering of
> the finalizers__ for the key and value (I will show why this is not a
> problem). 

Thanks for the summary John.  Actually this is the conclusion that Simon
& I came to about 2 minutes ago, without reading your message.

We need to be very clear about the difference between what you're
proposing and a stronger requirement on finalizer ordering.  In
particular, in your example, if the finalizer for k actually follows the
pointer to v, then you really need finalizer ordering and just liveness
dependencies won't do.

The GHC team's view is that we can implement finalizer dependencies
pretty easily (with weak pointers, of course), but doing finalizer
ordering is another kettle of fish altogether.  We think it's better to
steer well clear if at all possible, but the methods I outlined in my
previous message still apply (I think ordering finalizers placed on the
same object with addForeignPtrFinalizer is probably ok, and I'll
implement it in GHC when all this has settled down).

For Hugs & NHC, it would probably suffice to keep a list of dependencies
in the ForeignPtr.  After GC, you have to repeatedly traverse the live
ForeignPtrs making each of the dependencies live, until you can make no
more ForeignPtrs live, then finalize the dead ones.

Cheers,
	Simon