> I don't like runAtomically either, because once again it assumes a > global lock.
It has to be a global lock if we are to implement it on NHC and Hugs. Since we can't block finalizers once they start running, the only way to get atomicity is to stop them running. This requires use of a global lock unless we had (in advance, before the finalizer starts running) a list of the set of objects that the finalizer is going to access. It'd be hard to do this while treating libraries as black boxes. > This is fine for GHC or Hugs or NHC on single processors, but it > would be a pain if you had multiple processors. By 'pain' you mean slow? Since > 90% of uses of runAtomically will be with modifyIORef, we can avoid this overhead by providing atomicModifyIORef in the IORef library as well. Multiprocessor GHC is free to implement it more efficiently if necessary/ convenient. -- Alastair _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi