mallocForeignPtr vs. C

[Evan Laforge]

So I was planning to pass a StorableVector to C.  StorableVector uses
ForeignPtrs to manage its memory, so it should just be a pointer pass.
 I happily wrote up a reference counting scheme so I could attach
decref to the finalizer and have haskell and C cooperate about when to
delete the pointer.  However, then I found out that StorableVector
uses mallocForeignPtr, which says it already has the equivalent of a
free() finalizer attached, without actually using a finalizer.

So it looks like I can't safely pass it to C unless I also guarantee
that haskell still has a reference to it.  So the only thing I thought
of to deal with that is to pass C a FunPtr to a "wrapper" style
haskell function.  That function is never called, but it returns the
vector so the haskell GC can't free the vector while the function is
still alive.  Then when C is done with the vector, it can call
freeHaskellFunPtr via the usual freeHaskellFunPtr wrapper trick.

But I'm not convinced that's actually enough because the C code is
still running outside of a withForeignPtr.  I would have to do
something really hairy like call back to C from the haskell callback,
wrapping it in withForeignPtr.  Is there a better way to convince the
GC that the pointer should remain alive until I explicitly release it
from C?  The ideal I think would be a ref count that would keep the
pointer alive while >0, that could be decremented from C.

Since one of the advantages of ForeignPtr using types is to pass them
to C, this must be a problem someone has dealt with.  A synchronous
call that uses the foreign pointer temporarily is easy enough via
withForeignPtr, but what about when I want to share ownership with C?