Malcolm Wallace said, on Tuesday:
>
> In the FFI, the original object is indeed referenced within the
> finaliser, but the ForeignPtr is not. In fact, ideally the original
> object should be non-live in the main program from the very moment
> the finaliser is attached to it.
>
> Recall the signature of the operation:
>
> newForeignPtr :: Ptr a -> FunPtr (Ptr a -> IO ()) -> IO
> (ForeignPtr a)
>
> Once the ForeignPtr is created, the original Ptr can and must be
> discarded in the main program. The Ptr itself is kept live after that
> only by the finaliser: for the purposes of the rest of the program,
> the object has been transmuted into a composite ForeignPtr object
> that acts for all the world just like the original Ptr except that
> it has a different identity.
>
> I think this encapsulation and separation of types/values is
> an essential feature of finalisation in the FFI.
Just to add a different perspective here: rather than being an essential
feature of the FFI, I think of ForeignPtr as being an implementation
technique.
In GHC, when we allowed finalizers to be attached to any object rather
than being restricted to ForeignPtr (then ForeignObj), we thought we
might be able to do away with ForeignPtr altogether, and just attach
finalizers to Ptr (then Addr).
We would have, if it weren't for the fact that in GHC a Ptr isn't an
atomic type: it is a boxed version of the primitive unboxed Addr#.
Since the real underlying primitive type is unboxed, the garbage
collector can't keep track of it. So for GHC at least, the only reason
we need separate ForeignPtr and Ptr is because ForeignPtr wraps a
primitive type that is a heap object, whereas Ptr wraps an unboxed
address.
We now return you to the scheduled Haskell finalizer discussion...
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
