Finalizers strike back

[Alastair Reid]

> To sum up, it's NOT that I want the FFI standard to depend on
> concurrency.  It's once again that I don't want the FFI standard to
> depend on the absence of concurrency (as Alastair's IORef code
> does).


Please to not refer to that code out of context again.  I wrote that
code _specifically_ to demonstrate where race conditions could arise.
I clearly flagged it as code that "does nothing at all to guarantee
atomicity of Haskell code that manipulates global variables" and in
which "Some possible interleavings of the IO actions in these
functions can result in an object not being added to or removed from
the object list".

I think we are in full agreement that some form of locking is required
if Haskell finalizers that manipulate shared Haskell state are
allowed.

The only disagreement I see is:

1) Whether IORefs are a heavily used, widely implemented Haskell
   extension that the FFI standard cannot afford to ignore.

2) Whether providing a sufficiently powerful concurrency
   implementation is a sufficiently large burden that compelling FFI
   implementations to provide concurrency is unreasonable.

   (Sufficiently strong == finalizers are not starved, MVars can be
   used by finalizers.)

3) Whether we should specify something that we all know how to
   implement today and which we have 8 years experience of and
   consider revising it in the future as the shoe is demonstrated to
   pinch.

--
Alastair