I think you want to use "wrapper" functions from the FFI:
type HsPlayerFinalizer = Ptr PlayerStruct -> IO ()
foreign import ccall "wrapper" mkPlayerFinalizer :: HsPlayerFinalizer
-> IO (FunPtr HsPlayerFinalizer)
You can then make an arbitrary Haskell function (including a partially
applied function with closure state) into a FunPtr. You call
freeHaskellFunPtr when you are done with the function pointer.
I believe it's safe to do this from the finalizer itself; you can use
something like
mkFinalizerPlayer ptr file = mdo
finalizer <- mkPlayerFinalizer (createFinalizer finalizer file)
newForeignPtr finalizer ptr
where
createFinalizer finalizer file player = do
destroyPlayer player
fclose file
freeHaskellFunPtr finalizer
-- ryan
On 10/3/07, Maxime Henrion <mux at freebsd.org> wrote:
> Hello all,
>>>> I have recently developed a small set of bindings for a C library, and
> encountered a problem that I think could be interesting to others.
>> My problem was that the C function I was writing bindings to expects to
> be passed a FILE *. So, I had basically two possibles routes to take:
>> 1) Mimic the C API and have the haskell function take a Handle.
>> Unfortunately, I can see no way to go from a Handle to a Ptr CFile, at
> least no portable way, so I discarded this option.
>> 2) Deviate from the C API slightly and have the haskell function take a
> FilePath instead of a Handle.
>> This is the option I chose, and this is where things get interesting.
>> In order to pass a Ptr CFile (FILE *) to the C function, I had to call
> fopen() myself, using a usual FFI binding:
>> foreign import ccall unsafe "fopen"
> fopen :: CString -> CString -> IO (Ptr CFile)
>> That's the easy part. Now my problem was that I had to find a way to
> automatically close this FILE * when it isn't used anymore, in order not
> to leak FILE structures (and thus fds, etc). A finalizer is typically
> what I need, but unfortunately, a finalizer has a very strict shape:
>> type FinalizerPtr a = FunPtr (Ptr a -> IO ())
>> That is, a finalizer can only be a pointer to a foreign function, and
> the foreign function itself needs a quite specific shape.
>> And then I discovered Foreign.Concurrent, which allows one to associate
> a plain Haskell IO action to a pointer. The 'Foreign.Concurrent' name
> is a bit misleading to me; it seems this module is named so because it
> needs concurrency itself, rather than providing stuff for concurrency.
>> So, in the end, I've got this code:
>> import Foreign
> import Foreign.C
> import qualified Foreign.Concurrent as FC
>> ...
>> data PlayerStruct
> type Player = ForeignPtr PlayerStruct
>> ...
>> foreign import ccall unsafe "dd_newPlayer_file"
> dd_newPlayer_file :: Ptr CFile -> Ptr ImageStruct -> IO (Ptr PlayerStruct)
> foreign import ccall unsafe "&dd_destroyPlayer"
> destroyPlayerFinal :: FunPtr (Ptr PlayerStruct -> IO ())
>> foreign import ccall unsafe "fopen"
> fopen :: CString -> CString -> IO (Ptr CFile)
> foreign import ccall unsafe "fclose"
> fclose :: Ptr CFile -> IO CInt
>> ...
>> mkFinalizedPlayer :: Ptr PlayerStruct -> IO Player
> mkFinalizedPlayer = newForeignPtr destroyPlayerFinal
>> newPlayerFile :: FilePath -> Image -> IO Player
> newPlayerFile path image = do
> withCString path $ \cpath -> do
> withCString "rb" $ \cmode -> do
> file <- throwErrnoIfNull "fopen: " (fopen cpath cmode)
> withForeignPtr image $ \ptr -> do
> player <- dd_newPlayer_file file ptr >>= mkFinalizedPlayer
> FC.addForeignPtrFinalizer player (fclose file >> return ())
> return player
>> So I'm adding the "usual" finalizer, and with the help of
> Foreign.Concurrent, I can add a second free-form one (fclose file >>
> return ()), in order to close the file I opened at an appropriate time.
>> I'm looking forward hearing about other people's opinions, and wether
> this is a correct solution to the initial problem or not.
>> I think there is another way to solve this, which is to provide the
> finalizer still in haskell code, but export the haskell code using FFI,
> so that I can use it as a plain, normal finalizer. I'm still unsure
> about this.
>> Cheers,
> Maxime
> _______________________________________________
> Haskell-Cafe mailing list
>Haskell-Cafe at haskell.org>http://www.haskell.org/mailman/listinfo/haskell-cafe>