> 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 [EMAIL PROTECTED] Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/ _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi