The Death of Finalizers

[George Russell]

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.