> Sven says:
>
> > I'd like to finish discussion around the low-level aspects of the
> > FFI, so I propose the following: If none of the implementors yells
> > loudly that the ForeignObj FFI rule is costly to implement, this
> > lifetime rule should be left as it is. (It can't be hard to
> implement,
> > because as a fallback the StablePtr "trick" could be used.) We all
> > agree that it is easy and safe to use, and captures a common case.
>
> As the implementor of the primitive FFI in nhc98, I'm sitting here
> somewhat baffled. For us, the ForeignObj rule is not only easy to
> implement - it requires no implementation whatsoever! It would be far
> more difficult to try to get ForeignObjs to deallocate themselves
> randomly whilst they are still live. I remember this discussion of a
> so-called "special rule" for ForeignObjs from previously, and I still
> don't understand why it is "special" rather than the obvious and only
> way to do things.
The problem occurs when a ForeignObj is passed out into C land, and the C
function calls a foreign exported Haskell function, thereby re-entering the
Haskell RTS. If a garbage collection then happens, the original ForeignObj
may not be deemed to be alive unless the implementation takes specific steps
to ensure that it is.
Cheers,
Simon
