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