> (2) blockFinalizers looks fine for Hugs and NHC which only have a > single-thread model, but it looks tricky in general where [...]
Ah, I see what you mean. I'd kinda hardwired into the definition the assumption that finalizers run at higher priority than other threads and that there's a single execution thread. I'd hoped that blockFinalizers would be useful for defining other primitives but since it won't even work for GHC, I agree that PVar will meet most of our needs. (An even simpler design might be to extend our IORef implementations with 'atomicallyModifyIORef'.) So, is this a design that we could agree on? It seems a reasonable question to ask is whether either PVars or atomicallyModifyIORef could be used instead of MVars in existing concurrent code. If yes, then it seems likely that we can make our libraries Finalizer-safe. If no, it'll probably give us some clues as to what is missing and we can think about whether we'd miss them. A _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi