You do have to worry about the impact of running Haskell finalizers at any point during execution of Haskell code. Since you can't do any concurrency synchronisation between the finalizer and the main Haskell thread, shared access to mutable data is impossible. This is just something you'd have to document carefully (note, it's not something you can do with the current finalization mechanism either, but there it's obvious).
This is a pretty large restriction since the only reason for running Haskell finalizers is to manipulate shared Haskell state. Here's a typical example of where you would need Haskell finalizers instead of C finalizers: consider a simple graphics library which maintains a list of windows and deletes a window from the list when its finalizer runs (it presumably uses weak pointers to avoid the space leak). If the finalizer blindly deletes the object from the list, we get a race condition. If the object is protected by a lock, the finalizer can't access it. If we want to allow finalizers to access objects protected by a lock, we have to be prepared to block execution of the finalizer until the main thread releases the lock. I claim that Haskell finalizers are no use unless we provide synchronization primitives, those primitives are able to block execution of a currently running finalizer. I also claim that implementing blocking is a significant undertaking. Simon's patch doesn't make Hugs' concurrency implementation work with finalizers and it will take a fairly significant rewrite of the implementation to make it work. (At present, it doesn't work with unsafePerformIO.) I don't know if I'd be able to support blocking in any useful way without reimplementing the whole thing on top of a native thread library (pthreads, etc.) AFAIK, NHC does not implement any concurrency primitives so NHC would have to add them before it can provide any useful form of Haskell finalizers. -- Alastair Reid alastair@reid-consulting-uk.ltd.uk Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/