Proposed change to ForeignPtr

Manuel M T Chakravarty chak at cse.unsw.edu.au
Fri Aug 9 03:48:19 EDT 2002


Alastair Reid <alastair at reid-consulting-uk.ltd.uk> wrote,

> Since requiring ForeignPtr.newForeignPtr would require preemptive
> concurrency (see previosu discussion), I propose the following changes:
> 
> 1) Add these functions:
> 
>   makeForeignPtr :: Ptr a -> FunPtr (Ptr a -> IO ()) -> IO ForeignObj

I assume you meant

  makeForeignPtr :: Ptr a -> FunPtr (Ptr a -> IO ()) -> IO (ForeignPtr a)

>   attachForeignPtrFinalizer :: ForeignPtr a -> FunPtr (Ptr a -> IO ()) -> IO ()

What do you expect to happen if the finaliser calls a
foreign exported function?  (I am sorry, but I still haven't
been able to closely look at the entire ForeignPtr
discussion, so maybe this question was already answered
there.)

> 2) Remove newForeignPtr and addForeignPtrFinalizer
> 
> Two variants on this proposal:
> 
> 1) Reuse the old function names instead of inventing new ones.
> 
>    I don't care much either way.  

That's a tricky one.  From the standards point of view, I am
actually *very* reluctant to introduce new names.  On the
other hand, reusing the old names will lead to a couple of
unhappy emails from people using the old interface again.

Maybe we should have an -package old-ffi for compatibility.

> 2) Instead of removing the old functions, rename them and mark them
>    as an optional extra.  
> 
>    I think this would be a mistake - the GHC documentation is the
>    right place to mention extensions which are not available on all
>    ffi implementations.

We have avoided optional extras so far and I don't see a
reason to deviate from that policy now.  Moreover, it is
easy to define the old interface in terms of the new one
that you propose (given you can handle callbacks in
finalisers). 

Cheers,
Manuel



More information about the FFI mailing list