mallocForeignPtr vs. C

Felipe Lessa felipe.lessa at gmail.com
Mon Jul 12 19:26:07 EDT 2010


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.


More information about the Glasgow-haskell-users mailing list