> To sum up, it's NOT that I want the FFI standard to depend on > concurrency. It's once again that I don't want the FFI standard to > depend on the absence of concurrency (as Alastair's IORef code > does).
Please to not refer to that code out of context again. I wrote that code _specifically_ to demonstrate where race conditions could arise. I clearly flagged it as code that "does nothing at all to guarantee atomicity of Haskell code that manipulates global variables" and in which "Some possible interleavings of the IO actions in these functions can result in an object not being added to or removed from the object list". I think we are in full agreement that some form of locking is required if Haskell finalizers that manipulate shared Haskell state are allowed. The only disagreement I see is: 1) Whether IORefs are a heavily used, widely implemented Haskell extension that the FFI standard cannot afford to ignore. 2) Whether providing a sufficiently powerful concurrency implementation is a sufficiently large burden that compelling FFI implementations to provide concurrency is unreasonable. (Sufficiently strong == finalizers are not starved, MVars can be used by finalizers.) 3) Whether we should specify something that we all know how to implement today and which we have 8 years experience of and consider revising it in the future as the shoe is demonstrated to pinch. -- Alastair _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
