addForeignPtrFinalizer
Simon Marlow
simonmar at microsoft.com
Tue Sep 24 10:51:17 EDT 2002
> The spec says there are no guarantees on the order in which
> the finalizers
> are run. Doesn't this make this function almost impossible to use?
> Suppose one finalizer frees the storage and the other cleans
> up something
> it refers to. I'd suggest running the finalizers in the reverse order
> to the order they were added, i.e. the new finalizer will be
> run before
> any existing ones. Now that finalizers are FunPtrs, there should be
> fewer semantics problems.
Ordering of finalizers is not usually well-specified - I realise this
case is special (the finalizers are attached to the same object), but it
would still be quite tricky to implement in GHC. The reason is that for
each finalizer we create a new, independent, weak pointer that points to
the target object. (that's probably how we came to have
addForeignPtrFinalizer in the first place; it's a natural generalisation
in GHC, but perhaps not if you use a different implementation of
ForeignPtr. )
Cheers,
Simon
More information about the FFI
mailing list