Proposed change to ForeignPtr

[Simon Peyton-Jones]

I confess that I have not followed the twists and turns of this
discussion, but it seems to have gotten more complicated than necessary.
There are several separate issues.

1.  Can a finaliser for a Haskell value be an arbitrary Haskell
computation?  For GHC, yes.  For Hugs, no (and for good reasons).    So
Hugs can only allow a C procedure as a finaliser. 

2.  If a garbage collector (whether the Haskell gc or the Foogle gc)
finds that it is dropping a pointer to an object, when may it run the
finalizer?  Answer: it should be allowed to do so at any time: when the
pointer is dropped (for ref-count gc) or during gc (as Hugs does) or
after gc (as GHC does).

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.  

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.

Simon