Finalizers strike back

[Alastair Reid]

> [snip] I'm not sure I really understand the problem.  The FFI
> standard (Release Candidate 4, the one I have printed out here) does
> not define IORefs, and of course Haskell 98 doesn't either.
> Therefore, although this code is broken, this particular example
> doesn't matter if all we are considering is code written in Haskell
> 98 + FFI.

If there's no shared mutable Haskell state, writing finalizers in
Haskell buys you little - what does a finalizer do other than cleanup
shared state?  (Note that it doesn't cleanup unshared state - what
would be the point?)

I think IORefs are the most widely accepted extension of Haskell.  The
FFI spec doesn't depend on IORefs but it should certainly be designed
to work in an environment where they exist.

> However to me this code just looks totally wrong because of course I
> use GHC, a system with preemptive scheduling, and would regard it as
> incompetent to use anything other than an MVar here. 

I completely agree.

I do not believe we can have any useful form of Haskell finalizers
(meaning finalizers that manipulate shared Haskell state) without
adding MVars.

But, since concurrency is not so widely implemented as IORefs, we are
trying to produce an FFI design which does not require concurrency
extensions.

My solution to this conflict is not to add Haskell finalizers.

> However to me this code just looks totally wrong because of course I
> use GHC, a system with preemptive scheduling, and would regard it as
> incompetent to use anything other than an MVar here.  Even for Hugs
> I don't like this code, because [...]

I think you're taking my code out of context.  The purpose in writing
that code using IORefs was to show the kind of code you should not
write because it would suffer from race conditions.

I completely agree that some form of locking is required to make the
code safe. 

I guess I'd be willing to have Haskell finalizers if we agreed on an
appropriate form of locking that all implementers can and will
implement.

NHC currently lacks a locking mechanism.

I believe that using Hugs' MVars in conjunction with SimonM's patch
will lead to deadlock in the cases that would have suffered race
conditions using IORefs.

> Supposing we posit that there is a GlobalVariables standard.

Just want to remark that the variables don't have to be global.
Haskell finalizers are specified by closures and closures can point to
any IORefs you fancy.

> Anyone writing a finalizer should be aware (indeed the FFI standard
> should say) that the finalizer may be run at any point (after all,
> when else would you expect it to run) and should take precautions
> against it.  

What I hear you saying is that the FFI standard should depend on a
concurrency standard.  I think there was a strong sentiment that we
should avoid this.  I agree though that it is necessary if we allow
Haskell finalizers.


--
Alastair Reid                 alastair at reid-consulting-uk.ltd.uk  
Reid Consulting (UK) Limited  http://www.reid-consulting-uk.ltd.uk/alastair/