> Mon, 21 Feb 2000 10:20:30 +1100, Manuel M. T. Chakravarty
> <[EMAIL PROTECTED]> pisze:
>
> > I prefer a simple rule like ``when you pass a ForeignObj, you have
> > to take care if it can be the last reference and you don't want
> > it to be deallocated'' over a complex rule like ``if a ForeignObj
> > if passed in a prim type position, then ...; otherwise, ...''
> > The latter just complicates matters.
>
> On the one hand, I certainly would not be happy to add to all those 50
> foreign imports that use ForeignObjs code dealing with
> protecting them.
> There are only 3 cases where they are passed through a C
> array of Addrs
> (I arranged them such that finalizers won't hurt).
>
> On the other hand, if it means that a foreign import that
> calls back to
> Haskell (in extremely rare circumstances some can) could trigger the
> finalizer, which I'm not sure is always harmless in my case... Can it?
It can't: the rule is that the ForeignObj stays live at least until the
foreign call returns.
> Then it's bad. Otherwise IMHO they are safe and convenient enough, the
> unsafety if other cases is recognized by using foreignObjToAddr.
>
> I seek for a safe, simple and cheap way of protecting ForeignObjs
> across C calls, rarely across a bit more than a C call. The StablePtr
> trick, if would be required, has a flaw: when forgotten, silently
> leads to incorrect code.
Agreed. I don't see the problem here: isn't it straightforward to say that
"if you need to use foreignObjToAddr, then you also need to add some
explicit control over the lifetime of the foreign object, possibly using a
StablePtr". The rule about keeping ForeignObjs live over a foreign call is
exactly what you want in most cases, IMHO.
Cheers,
Simon
