> > 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). > [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. Cheers, Simon PS. I'm sorry to keep banging on about this. Ultimately it doesn't really matter to me that much, since I only really use mallocForeignPtr. I guess I was just intrigued to see if the problem was really as difficult as we'd thought. _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi