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. _______________________________________________ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
