2009/12/14 Donn Cave :

I'm working with a C++ application library, of the sort where you instantiate a subclass of the library object and it dispatches your functions on receipt of various events.  With multiple OS threads, by the way.

This works all right so far, with some C++ boilerplate and Haskell FunPtrs created via the foreign "wrapper" option, but I am not crazy about marshalling the application data, to get it to the C++ object and back to my application functions.

So, I'm wondering if the way I'm trying to thread application data through the C++ layer is reasonably fool-proof - I mean, empirically it works in a simple test, but are there going to be storage issues, etc.?  Is there a better way to do it?

Briefly,  - my callbacks        AppData -> CPlusObjectPtr -> P0 ... -> IO Pn  - the FunPtr inserted into C++ object        FunPtr (CPlusObjectPtr -> P0 ... -> IO Pn)        ... i.e, I apply the AppData parameter first  - I rewrite the C++ object's FunPtrs every time I update the    application data (freeHaskellFunPtr prior values.)

I'm just not sure where AppData lives while it's referenced in a FunPtr via partial application, if there might be multiple copies, etc.

I don't fully understand what you want to do, but perhaps you can use a StablePtr: http://www.haskell.org/ghc/docs/latest/html/libraries/base/Foreign-StablePtr... Cheers, Bernie.

Hello Donn, Monday, December 14, 2009, 4:31:58 AM, you wrote:

I'm just not sure where AppData lives while it's referenced in a FunPtr via partial application, if there might be multiple copies, etc.

GHC RTS creates thunk with this partial call. this thunk references all the data used in computation. The thunk is placed in global objects table and removed from the table when you perform freeHaskellFunPtr -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com