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)
_______________________________________________
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
