Finalizers strike back

Fergus Henderson fjh at
Fri Oct 11 12:14:25 EDT 2002

On 11-Oct-2002, George Russell <ger at> wrote:
> I think we should remember that the FFI standard has to address various
> audiences
> (1) those who want to implement portable code in just FFI + Haskell98.
> This group does not have access to functions for conveniently manipulating
> mutable state, therefore Alastair's problem with IORefs will not be a problem
> for them. However Haskell inside finalizers will at any rate not harm them

This argument is invalid, because those who want to implement portable
code in just Haskel98 + FFI will very quickly use the FFI to implement
IORefs or something similar.

> Consider someone who, say, calls out from Haskell to Java (to do funny
> graphics, say) and writes a finalizer which calls Java code.  At the same time, they
> also want to do some completely separate pure computation in Haskell, which is made
> available to Java.  Since Java at least does have preemptive concurrency, while
> it is running at all, it is perfectly possible that Java will call the Haskell computation
> while the Java finalizer is running.  You want a license to make the roof fall in at this
> point; I don't think you should have it.

If you have a non-thread-safe Haskell implementation, and you try to
call it from two different threads without protecting this somehow,
then the roof *will* fall in at least some of the time.  This follows
directly from the definition of "non-thread-safe".

So you want to disallow non-thread-safe Haskell implementations from
supporting the FFI?

Fergus Henderson <fjh at>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <>  |     -- the last words of T. S. Garp.

More information about the FFI mailing list