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