mallocForeignPtr vs. C

On Mon, Jul 12, 2010 at 5:23 PM, Evan Laforge <qdunkan at gmail.com> wrote:
> Another hack I thought of:
>> - store ptr in a global MVar in haskell, pass it to C
> - C does its thing, ptr stays alive because haskell still has a reference
> - now when C calls the finalize funptr, it deletes the ptr from the
> haskell MVar, which releases haskell's hold on it
I would go with this path, however...
> Effectively, this is using the global MVar as a GC root instead of the
> funptr itself. I'm much more confident that the GC is going to follow
> module level CAFs than some random funptrs allocated with a foreign
> "wrapper" call. However, the "wrapper" calls must serve as GC roots
> too, because otherwise what guarantees that variables captured in its
> closure stay alive? Right?
... I would try to avoid having the MVar/IOVar as a CAF because of its
unpredictability. You can always encapsulate it as somewhere else
(e.g. Reader monad).
Hipmunk has a similar problem of having to keep things alive, and I
just stash everything in a Data.Map inside a pure Haskell structure.
But that's because in Hipmunk the objects are destroyed after they are
explicitly removed, and this is done on Haskell land. I don't need to
kill anything from C.
Cheers,
--
Felipe.