Finalizers etcetera

George Russell ger at
Wed Oct 2 12:32:24 EDT 2002

In fairness I should state that here at Bremen we do not currently need Haskell finalizers.
I was thinking of another application altogether, but I don't particularly want to go into
details of that.  There are however particular reasons (such as galloping concurrency) why
I think Alastair's proposed hooks would be impractical in that case, even if they were
provided by both garbage collectors, which they wouldn't be.

I don't think we are coming any nearer to a solution on this.  There seem to be three proposals:
(1) Alastair's: keep the signature as it is, with the restriction.  Add miscellaneous hooks
allowing C to do things to the Haskell world without actually entering it.
(2) Mine: keep the signature as it is, but remove the restriction, at least so that if implementations
decide to impose the restriction anyway, they have to document it very clearly.
(EG "Hugs implements the FFI standard [ref]" with the restriction that finalizers may not call
back into Haskell (see paragraph [whatever]").
(3) Manuel's: reverse the change altogether.

Ideally I'd like Manuel's solution, except that we obviously can't force Hugs and NHC to comply
with it.  I think therefore I prefer my solution in that it makes clear you can write simple
portable FFI code which runs on any implementation with or without the restriction, but non-trivial
use involving interaction with foreign garbage collectors and the like is likely to fall over.

I don't deny that it is likely to be possible to write non-trivial applications involving
finalizers in several languages even in Hugs, but you will have to provide various hooks which are in 
general quite inappropriate.  Other choices might be some kind of lock which could be operated from both 
the Haskell and C world (since then it would be possible, painfully, for a C finalizer to arrange for a 
Haskell thread sleeping on the lock to wake up, if enough scheduling points arise).  Or as Alastair
suggested, you can at least arrange for some Haskell functions, like freeStablePtr, to be made
available in the C world.  Such things might be a good idea in Hugs or NHC (obviously it's not for
me to say), if Haskell finalizers really are impossible.  But in general I think it is simply absolutely inappropriate for such solutions to be specified in the standard, since they seem to assume too much
and impose too much work on the user, if the user is happy to use GHC.

More information about the FFI mailing list