George Russell <[EMAIL PROTECTED]> writes:
> We might
> very reasonably have situations where fairly complex inter-language
> pointers exist, so for example Haskell holds a ForeignPtr to something
> in the Foogle heap; the pointed-to Foogle object in turn references a
> Haskell object (presumably provided via StablePtr). Now suppose Haskell
> wants to drop the ForeignPtr. Then the logical thing for the finalizer
> to do is to tell Foogle that Haskell is no longer interested in the
> Foogle object. This then gives Foogle the chance on its own garbage
> collection to in turn drop the Haskell StablePtr. In turn this means
> somehow running StablePtr.freeStablePtr. However this scheme I don't
> know if that's legal, because the Haskell finalizer you need to run
> "freeStablePtr" is indirectly provoked by the initial Haskell finalizer.
I don't see the problem. The Foogle garbage collector runs separately
and asynchronously to the Haskell GC. A Foogle object is released
by the Haskell collector, then at a later moment in time, a Haskell
object is released by the Foogle collector. Where is the conflict?
> Of course you
> would need at least reference counters (if you can guarantee there are
> no cycles containing both languages) or something more powerful
> otherwise, but reference counters at least can be provided.
Why do you suggest a need for reference counts? In the absence
of cycles, surely the existing two garbage collectors (howsoever
implemented) are sufficient.
> I'm afraid I haven't been following this thread lately, so I don't know
> what the big problem is about calling Haskell from a finalizer; I
> suppose it's something to do with us being in the middle of garbage
> collection.
There is only a problem if Haskell is called directly by a finaliser
since, as you noted, there is no heap available to run the finaliser.
An indirect Haskell call triggered at some indeterminate point in
the future, but in any case after the Haskell GC has completed,
is no problem at all.
Regards,
Malcolm
_______________________________________________
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
