Finalizers finalized

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.

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,

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.

void hs_free_stable_ptr (HsStablePtr sp);
void hs_free_fun_ptr    (HsFunPtr fp);

to the spec.

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

There have neither been positive nor negative comments.

Proposed action: Revise the spec for

* 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
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
`