freeHaskellFunPtr

[Sven Panne]

Alastair Reid wrote:
> This looks fairly delicate [...]

Agreed.   :-}

> It seems like your example could be handled by calling the free
> function in the Haskell code that invokes the C code that invokes the
> callback: [...]

My Haskell callback is actually a one-shot timer callback from GLUT, and
I'm not directly "invoking the C code that invokes the callback": After
an initial setup phase, *everything* is callback-driven, so your proposal
is not a solution here.

> How much worse would it be to write your code in this way?

Hmmm, it looks like I have to resort to a "global variable" hack for
tracking the (un-)registration of other callbacks, anyway. The problem
is as follows: If you repeatedly set or clear a Haskell callback, you
have to track what the C side already knows on the Haskell side, too,
just for freeHaskellFunPtr.   :-P   The additional problem with those
one-shot callbacks is that only the callback knows when to deregister.

In a nutshell: I'm not very happy with the explicit allocation and
deallocation of the 'foreign import wrapper' thunks. They are an
artefact of the Haskell implementations and look strange in an
otherwise GC-ed world...

Anyway, the documentation of freeHaskellFunPtr should be made a little
bit clearer about what we decide.

Cheers,
   S.