Sven_Panne at BetaResearch.de
Tue Jun 18 05:15:25 EDT 2002
Alastair Reid wrote:
> This looks fairly delicate [...]
> 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.
More information about the FFI