[Alastair Reid <alastair@reid-consulting-uk.ltd.uk>] Re: cvs commit: haskell-report/ffi finalizers.txt

[Alastair Reid]

Oops, I sent the attached document to the wrong mailing list.  This is
a comment on SimonM's finalizer document.  I decided to comment rather
than edit since my comments require more than tweaking the odd word
here and there.

--
Alastair


Things you mights add are:

eg(1) in composite finalizers:

  This would be handled just fine by C finalizers if
  addForeignPtrFinalizer guaranteed to execute finalizers in reverse
  order of their addition.  This seems like a reasonable thing to
  specify since addForeignPtrFinalizer is much less useful if this
  guarantee doesn't hold and because it is easy to implement.

eg(2):

  isn't too convincing since you could easily write the same thing in
  C.  I expect you could find something more convincing with a little
  effort.


Communicating with a foreign runtime/garbage collector:

  I remain unconvinced that this example has been worked out in detail
  and believe that if it were worked out in detail we'd either find
  that all George needs is to be able to call into the _runtime
  system_ during a Java GC (doesn't require Haskell finalizers) or
  that he requires a much more intimate relationship with Haskell's GC
  (requires a lot more than the FFI provides).

Other cleanups:

1)
  Unsavouriness of exporting &free seems like a judgement an impartial
  witness would avoid.

2)
  Whilst "the philosophy of the FFI is to move as much marshalling
  machinery into Haskell as possible," the existence of an ffi
  suggests that foreign code does have a useful role and one could
  argue that finalizing foreign objects is one of those roles.


Manipulating mutable state and communicating with other threads:
  
  I don't see how adding concurrency strengthens the argument for
  Haskell finalizers.  
  
  Adding mutable Haskell state doesn't seem to strengthen it either.
  Indeed, I assume the existence of mutable Haskell state in arguing
  against Haskell finalizers.
  

Arguments against:

  Adding Haskell finalizers drags in many concurrency issues for
  programmers:
  
  - potential to introduce race conditions
  - potential for deadlock
  
  As with most concurrency issues, the resulting bugs are easy to
  introduce, hard to reproduce and hard to track down.
  
  Adding Haskell finalizers has a high implementation burden for those
  who have not already implemented preemptive concurrency - greatly
  increasing the complexity of implementing Haskell + FFI (+ mutable
  state, of course - but that is a trivial thing to implement).
  
  The complexities introduced seem out of line with the problem being
  solved.
  

Implementations/Hugs:

  You say: "There is some doubt over whether the patch is safe as it stands:"
  I say: "There is no doubt that the patch is unsafe as it stands:"

Implications of allowing Haskell finalizers in non-concurrent systems/Mutable state:

  You omit my argument that, since the primary goal of finalizers is
  to modify mutable state, Haskell finalizers which do not modify
  mutable Haskell state will be of little use.  All they will be able
  to do is lookup objects in immutable Haskell state and invoke C
  finalizers to do their work - a significant limitation.  (In
  fairness, I will say that useful information might be stored in the
  finalizer closure so actions like looking up an object in a binary
  tree of all live objects (say) might be avoidable with a little
  effort.)

Interaction with co-operative concurrency:

  You say (though your final paragraph suggest you don't insist on it):

    One might argue that since you have to do this anyway in Hugs -
    another thread can only get control at an explicit yield point -
    doing it for finalizers too isn't so bad.
  
  I say:

    There is a world of difference between being delayed for an
    unknown, finite amount of time and being delayed for an unbounded,
    potentially infinite amount of time.  (This is why vague concepts
    like 'fairness' are useful in reasoning about scheduling - you
    don't know when you will run but you know you will get a shot
    sometime.)


Proposals:

Add:

  4) No change to the spec for the time being, while we evaluate the
     need and cost of implementing Haskell finalizers in a range of
     implementations.  Note that upgrading from C finalizers to
     Haskell finalizers would only require that we say that finalizers
     are invoked with the equivalent of a 'safe' ffi call instead of
     an 'unsafe' ffi call and, no doubt, the addition of some
     convenience functions.

I don't think this is the same as (3)