Malcolm Wallace <[EMAIL PROTECTED]> wrote,
> 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.
It isn't that trivial in general. In particular, IIRC, this
rule wasn't implemented by ghc a while ago. In case of a
tail call to a C routine, ghc could deallocate the stack
frame of the caller (which might hold the last reference to
the ForeignObj) _before_ calling C, and then, the object
could be gc'ed during a re-entry to Haskell from C.
In nhc, the problem doesn't occur because of the closures
that you build for every foreign call - at least that was
the explanation that you gave me a while ago. In some
sense, it is nhc's lack of tail call optimisation in case of
C calls that makes the issue seem trivial to you.
Manuel
