Finalizers strike back
alastair at reid-consulting-uk.ltd.uk
Fri Oct 11 08:27:55 EDT 2002
> 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
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
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
More information about the FFI