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.