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.
I'd also like to see the addition of mallocForeignPtrArray :: Storable a => Int -> IO (ForeignPtr a) to ForeignPtr, to save people from rolling their own. (Maybe the realloc and 0 versions too?)
Ross Paterson <ross@soi.city.ac.uk> wrote,
I'd also like to see the addition of
mallocForeignPtrArray :: Storable a => Int -> IO (ForeignPtr a)
to ForeignPtr, to save people from rolling their own. (Maybe the realloc and 0 versions too?)
The reason I didn't answer to this earlier is that I wanted to see how many people say that they support this addition. To be honest, I never needed a function like this. Did anybody else? Manuel
On Fri, Jan 17, 2003 at 10:23:27AM +1100, Manuel M T Chakravarty wrote:
Ross Paterson <ross@soi.city.ac.uk> wrote,
I'd also like to see the addition of
mallocForeignPtrArray :: Storable a => Int -> IO (ForeignPtr a)
to ForeignPtr, to save people from rolling their own. (Maybe the realloc and 0 versions too?)
The reason I didn't answer to this earlier is that I wanted to see how many people say that they support this addition. To be honest, I never needed a function like this. Did anybody else?
Only me, it seems. But surely if both mallocForeignPtr and mallocArray are useful, this is too. If you don't want to do explicit deallocation, mallocForeignPtr is attractive (and handled specially by GHC). Sooner or later there are going to be arrays, and then if there's no such function you'll have to write your own.
Ross Paterson <ross@soi.city.ac.uk> wrote,
On Fri, Jan 17, 2003 at 10:23:27AM +1100, Manuel M T Chakravarty wrote:
Ross Paterson <ross@soi.city.ac.uk> wrote,
I'd also like to see the addition of
mallocForeignPtrArray :: Storable a => Int -> IO (ForeignPtr a)
to ForeignPtr, to save people from rolling their own. (Maybe the realloc and 0 versions too?)
The reason I didn't answer to this earlier is that I wanted to see how many people say that they support this addition. To be honest, I never needed a function like this. Did anybody else?
Only me, it seems. But surely if both mallocForeignPtr and mallocArray are useful, this is too.
If you don't want to do explicit deallocation, mallocForeignPtr is attractive (and handled specially by GHC). Sooner or later there are going to be arrays, and then if there's no such function you'll have to write your own.
Yes, I think you are right that an orthogonality argument can be made here. So, let's add the function. I assume from the silence on this topic that nobody has an serious objections to adding this function. `mallocForeignPtrArray0' should then also be added, as you say. I am not so sure about a realloc version. It, at least, requires some care, as realloc may return a pointer different from the original. (In other words, there is no guarantee that realloc works in-place.) I just noticed that the spec doesn't mention this; so, I'll add it. We should also include the special cases that the C library covers: * If `realloc' is passed a `nullPtr', it works like `malloc'. * If the size requested from `reallocBytes' is 0, it works like `free'. Finally, I am not sure whether we really want to allow that `reallocBytes' may be used on `alloca'ed memory, which the spec currently explicitly admits. Proposed changes ~~~~~~~~~~~~~~~~ Add to `ForeignPtr': mallocForeignPtrArray :: Storable a => Int -> IO (ForeignPtr a) mallocForeignPtrArray0 :: Storable a => Int -> IO (ForeignPtr a) Refine spec of `MarshalAlloc' as follows: * realloc may return a pointer other than the one passed in. State special cases for passing `nullPtr' and size of 0, respectively, to `realloc' as stated above. [I will already apply these changes.] Open questions (feedback requested) ~~~~~~~~~~~~~~ * Shall we remove the sentence allowing `reallocBytes' on `alloca'ed memory? * Shall we provide reallocForeignPtrArray and reallocForeignPtrArray0? [I will not apply these changes until after further discussion.] Cheers, Manuel
On 22-Jan-2003, Manuel M T Chakravarty <chak@cse.unsw.edu.au> wrote:
Finally, I am not sure whether we really want to allow that `reallocBytes' may be used on `alloca'ed memory, which the spec currently explicitly admits.
I agree, allowing this is a bad idea. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit The University of Melbourne | of excellence is a lethal habit" WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
Manuel M T Chakravarty wrote:
[...] 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. [...]
This was simply a typo.
[...] [NB: Sven already added the functions with the "*" in the signature to GHC's `HsFFI.h'. These would need to change.]
... and need to be actually implemented. :-) Cheers, S.
participants (4)
-
Fergus Henderson -
Manuel M T Chakravarty -
Ross Paterson -
Sven Panne