Proposed change to ForeignPtr

George Russell ger at tzi.de
Wed Sep 11 04:13:01 EDT 2002


Simon Peyton-Jones wrote:
[snip]
> 3.  If the finalizer, in turn, needs to call some kind of foreign 'free'
> routine (e.g. the finaliser for a Haskell object encapsulating a Foogle
> object calls the Foogle free code; or the finalizer for a Foogle object
> encapsulating a Haskell value calls the Haskell free routine) it should
> be allowed to do so at any time.   BUT DOING SO DOES NOT trigger an
> immediate GC in the other system.
[snip]
I think the problem is that you may want it to trigger arbitrary computation
at some time.  For example if Foogle wants to let go of a Haskell StablePtr,
you may want to decrement (in Haskell) some reference counter associated with
the StablePtr.  Or indeed do some more complicated operation if you are worried
about circular datastructures which cross languages.  This is why I don't think
Alastair's suggestion of providing C with access to StablePtr.freeStablePtr
is enough.  However this computation doesn't have to be "immediate"; the Haskell 
RTS could reasonably delay it until the GC is over.


> Several people have explained why it would be bad to trigger immediate
> GC. All the 'free' routine does is record that Foogle no longer holds
> this pointer (or vice versa).  That information (as Alastair puts it)
> tweaks local data structures (yes, there may need to be a lock if there
> are separate OS threads involved), and that info is exploited at the
> next GC.
> 
> 4.  None of this says anything at all about asynchronous calls into
> (say) Haskell from Foogle.  I don't understand what the issues are
> exactly.
Suppose Hugs and GHC are running in the same OS thread, calling each other.
GHC is running various threads which call Hugs functions.  At the same time
Hugs has finalizers which somehow call GHC.  If I understand the situation
correctly, during the called GHC functions the GHC RTS functions normally,
meaning the other GHC threads get run, meaning the Hugs functions get called,
meaning (presumably) horrible chaos.  If it seems pointless linking Haskell with
Haskell, substitute Java for GHC.



More information about the FFI mailing list