Sigbjorn Finne <[EMAIL PROTECTED]> wrote,
> Manuel M. T. Chakravarty <[EMAIL PROTECTED]> writes:
> >
> ....
> > > Passing foreign objects directly via the FFI does not have this
> > > problem, because there is a special lifetime guarantee for this
> > > kind of values. :-P
> >
> > Actually, doesn't that prove the point that I tried to make
> > when we discussed this previously, namely that the "special
> > lifetime guarantee" isn't a very good idea in the first
> > place? It's a kludge. As soon as a ForeignObj is not
> > passed as an explicit argument to a C function, but as part
> > of a compound data structure, the kludge breaks.
> >
> > As SimonM said in a previous email (and Michael Weber
> > pointed out in our earlier discussion), if you pass a
> > ForeignObj to C and want to be sure that it doesn't get
> > finalised, you have to StablePtr it. Why should there be a
> > difference between the case where the ForeignObj is passed
> > as an individual argument and the case where it is passed as
> > part of a compound structure?
>
> Because the latter you have control of how it is marshalled
> (it is not a prim type), while the former you don't.
You have equal control in both cases - or more precisely,
you should have equal control in both cases. My point
exactly is that the FFI shouldn't attempt to be clever if it
can't in the general case. 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.
> Call it a kludge if you wish, but I prefer the FFI to be safe.
It isn't save anyway. The current rule pretends to be safe,
but fails in subtle ways. I prefer a clear rule.
> > The only excuse that I see at the moment is that the special
> > lifetime guarantee saves some typing in the common case -
> > not a very good excuse for an awkward language feature,
> > I think. Especially, as we can handle this case also nicely
> > in the FFI marshaling library (by providing a wrapper that
> > does the `StablePtr'ing).
>
> So, you're saying that if you've got an object reference to
> some external (CORBA?) object, you want to allocate a StablePtr
> everytime you pass it out & de-allocate it upon return? Sounds
> a bit OTT to me.
Much of the "overhead" of StablePtrs at the moment is due to
the hash table and reference count business that is
implicitly performed by the stable pointer routines. So
far, I haven't seen a good explanation as to why this is
actually needed. If we would get rid of it, StablePtrs
would be much more light weight.
Manuel
