Manuel M T Chakravarty
chak at cse.unsw.edu.au
Mon Jan 13 09:15:54 EST 2003
Sorry for taking so awfully long with a wrap up of the
finalizer affair, but here it is.
* 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
- Two important points have been ignored in this part of
(1) FFI RC 6 already included C finalizers *and* used
the original names (`newForeignPtr' and
`addForeignPtrFinalizer') after we discussed this
(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
* Should there be a guaranteed execution order for multiple
finalizers on a single object? Alastair argues for this
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
I'll state my reasons in a direct reply to the above
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.)
\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.
More information about the FFI