Finalizers strike back
fjh at cs.mu.OZ.AU
Fri Oct 11 12:14:25 EDT 2002
On 11-Oct-2002, George Russell <ger at tzi.de> wrote:
> I think we should remember that the FFI standard has to address various
> (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.
More information about the FFI