Sorry for taking so awfully long with a wrap up of the finalizer affair, but here it is. Unanimous agreement: * Alastair was right: Haskell finalizers require pre-emptive concurrency => C-finalizers only in FFI 1.0 Still under discussion: * Names for the C-finalizer functions: - A number of people have called for names other than those originally used for Haskell finalizers; in particular, an inclusion of the word "unsafe" was proposed. - Two important points have been ignored in this part of the discussion: (1) FFI RC 6 already included C finalizers *and* used the original names (`newForeignPtr' and `addForeignPtrFinalizer') after we discussed this point before. (2) Hugs Nov2002 already implements the FFI RC 6 API. Alastair mentioned that before the release and shortly after it was discovered that Haskell finalizers won't make it into the FFI spec. I think we owe it to the Hugs people to stick to `newForeignPtr' and `addForeignPtrFinalizer' now. Besides, I also think that these names are better. As Alastair mentioned, these are the only finalizer primitives in the FFI, so it is a bit strange if they are labeled unsafe. Please also note that the unsafeness is different from that in other functions that contain the word "unsafe" (like `unsafePerformIO'). Hence, I don't think it would really make the meaning clearer and being more precise in the names would make them pretty long. Proposed action: leave the names as published in FFI RC 6 * Alastair proposed the addition of void hs_free_stable_ptr (HsStablePtr x); The name is consistent with the rest of the FFI C API and has already been included into Hugs Nov2002. Moreover, Sven already added void hs_free_stable_ptr (HsStablePtr *sp); void hs_free_fun_ptr (HsFunPtr *fp); to the CVS version of the spec a while ago. I am not sure whether the "*" in the signatures was a mistake. Maybe the idea was to pass a pointer to the pointer that is to freed in and have the freeing function set that to 0L. However, I think, it is better to go with the interface suggested by free() and already implemented in Hugs. Proposed action: Add void hs_free_stable_ptr (HsStablePtr sp); void hs_free_fun_ptr (HsFunPtr fp); to the spec. [NB: Sven already added the functions with the "*" in the signature to GHC's `HsFFI.h'. These would need to change.] * Should there be a guaranteed execution order for multiple finalizers on a single object? Alastair argues for this in http://haskell.org/pipermail/ffi/2002-November/000990.html There have neither been positive nor negative comments. Proposed action: Revise the spec for `addForeignPtrFinalizer' to read as attached below. * `touchForeignPtr', `keepAlive', and `ForeignDependency': To be honest, I don't buy into the motivation for `keepAlive' and friends from http://haskell.org/pipermail/ffi/2002-October/000942.html I'll state my reasons in a direct reply to the above message. Proposed action: leave `touchForeignPtr' as it is in FFI RC 6 * The `Proxy' story: The discussion seemed to have trailed off without a real conclusion. I'll write a seperate email on this. Any *serious* objections? (I already executed the above proposed actions on the CVS version of the spec.) Cheers, Manuel -=- \item[addForeignPtrFinalizer ::\ ForeignPtr a -> FunPtr (Ptr a -> IO ()) -> IO ()] Add another finalizer to the given foreign pointer. All finalizers associated with a single foreign pointer are executed in the opposite order of their addition---i.e., the finalizer added last will be executed first.