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.
Sven:
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...
I think they're explicitly deallocated (and, hence, explicitly allocated) because C uses explicit allocation/deallocation. The expectation is that the function pointer will be handed to C and that C code will be responsible for deallocating the function. I'm at something of a loss for how GC support would help with your example. How would Haskell's GC know that the one and only call to the wrapper had just been made? Incidentally, I'd like to add a Haskell version of freeHaskellFunPtr to the C interface: extern void hs_free_haskell_funptr( HsFunPtr x ); Of course, it can always be foreign exported (and compilers might even implement it that way) but I think we'll find that every major library exports its own copy and, since there's only so many obvious variants on the Haskell name, we'll quickly run into name conflicts which will then be resolved in the usual ugly way. I recognize that this is the top of a slippery slope which will quickly plunge us into a situation of exporting a whole bunch of functions for manipulating ffi-related datatypes. I'm not sure that's such a bad thing though. -- Alastair
participants (2)
-
Alastair Reid -
Sven Panne