"Simon Marlow" <[EMAIL PROTECTED]> wrote, > > > Then I'll reformulate my question as a patch. [...] > > > Is there anything fundamentally wrong with this approach? > > > > I still maintain that getting this to work, testing it and, > > especially, maintaining it is a lot of work. > > Isn't it worth a little effort? Requiring finalizers to be foreign > functions is a serious wart in the FFI, especially when we're strongly > advocating that as much marshalling should be done in Haskell as > possible. > > As for the testing and maintenance, you can see from the patch that the > changes are quite small and mostly obviously correct. The only > difficult correctness property is whether it's ok to have eval() invoke > runIO() and thereby eval() recursively, but the reasoning is simple: > from eval() you can already call a foreign function, and foreign > functions can invoke foreign-exported Haskell functions, which in turn > re-enter eval() through runIO(). So the patch doesn't add any new > invariants. > > You do have to worry about the impact of running Haskell finalizers at > any point during execution of Haskell code. Since you can't do any > concurrency synchronisation between the finalizer and the main Haskell > thread, shared access to mutable data is impossible. This is just > something you'd have to document carefully (note, it's not something you > can do with the current finalization mechanism either, but there it's > obvious).
I have to say that, given Simon's patch, I am inclined to revert back to the old API for foreign pointers. The restriction on pure C land finalizers *is* awkward, and as we have already seen implies further changes (ie, adding something like `finalizerFree'). It surely would have been too much to require a Haskell system to implement pre-emptive concurrency just to support finalizers, but a change along the lines of Simon's proposal doesn't seem to be too much trouble for a much nicer design (which I regard Haskell land finalisers to be). > > [For example, you > > mention that finalizers that point to the object they finalize don't > > work. I guess we could fix that by adding GHC-style WeakPtrs.] > > This isn't as big a problem as it sounds. The finalizer can refer to > the Ptr, just not the ForeignPtr. If it is essential to refer to the > ForeignPtr (I can't think of a reason why it should be), then we could > change the spec so that it was passed as an argument to the finalizer. I'd be perfectly happy to add a restriction to the spec that finalizers must not refer to their ForeignPtr (if they are ever to run) and instead pass it as an argument to the finalizer. Still much better than these awkward C land finalizers. Cheers, Manuel _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
