RE: Proposed change to ForeignPtr
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
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.
participants (2)
-
George Russell -
Simon Peyton-Jones