addForeignPtrFinalizer

[Manuel M T Chakravarty]

"Simon Marlow" <simonmar at microsoft.com> 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