Simon Marlow wrote
Ok, I'm sad to say that the problem we recently uncovered to do with finalizers sharing values with the rest of the program essentially kills off the possibility of doing Haskell finalizers in systems without proper concurrency support. I'm rather embarassed that I didn't notice this before; sorry for wasting everyone's time :-(
Let's keep C finalizers for the FFI spec. In GHC I imagine we'll continue to offer Haskell finalizers as an extension, but I haven't decided on an interface yet (suggestions welcome).
From now on I intend to keep track of a strict quota that prevents me from writing more email than code :-) [snip] How sad. It's an unfortunate hole in the specification and I hope someone will come up with a way of fixing it someday.
In the meantime, I'm glad we have got a new function atomicModifyIORef which I for one will use, when it gets into GHC's regular release. It's really nice that we can use laziness to safely update a mutable value without blocking. Another nail in the coffin for Standard ML. I think the addForeignFinalizer function or whatever it is should nevertheless be renamed to addUnsafeForeignFinalizer (and likewise for newForeignObject). There seems no more justification for labelling such foreign finalizers as "safe" than for labelling unsafe foreign function calls as "safe". Also I suppose Alastair's hs_freeStablePtr function which allows you to do it from C, or whatever, will have to be added. I hope Alastair will forgive me for engaging him in such a lengthy argument, when he turns out to have been right all along.