Yes, you cannot reliably free 'yourself' when using the C calling
convention and "foreign export dynamic". Good point, I've committed
a fix for this.
If I understand your scenario right, that only leaves getting at
the address of the old-Haskell-callback-to-be-nuked, but it's
reachable without too much bother..?
--sigbjorn
BTW, IOExts.freeHaskellFunctionPtr has also been added.
Sven Panne <[EMAIL PROTECTED]> writes:
>
> Alas, the saga continues: After a thinking a little bit more about
> Simon's and Sigbjorn's replies to my question, I'm now convinced that
> it is not as simple as it seems, because there are *two*
> kinds of pointers
> in this game. Again my scenario, this time a little bit more verbose:
>
> 1. Create a callback via foreign export dynamic. This gets you an
> Addr, which is basically a pointer to a block of machine code
> malloc'ed and filled by createAdjustor. The code contains a
> stable pointer to the Haskell closure to be called.
> 2. Register the Addr from step 1 to the C-API (GTK+, GLUT, etc.)
> 3. After a while, the adjustor code is called from C-land, which in
> turn calls the Haskell callback via the stable pointer.
> 4. The Haskell callback wants to re-register a new callback for the
> same event. It is *not* allowed to call freeHaskellFunctionPtr
> with the Addr from step 1 at this point, because of step 6.
> 5. The running "old" callback can still do anything it pleases
> 6. The callback finishes and control passes through the code block
> from step 1, finally reaching C-land again.
>
> In step 4, freeHaskellFunctionPtr would (correctly) free the stable
> pointer to the Haskell callback, but in addition it would free the
> malloc'ed block, which is still needed in step 6.
>
> Is it now me who missed something? I'm getting a little bit
> confused...
>
> Cheers,
> Sven
