Finalizers strike back

[Fergus Henderson]

On 11-Oct-2002, George Russell <ger at tzi.de> 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 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.