Manuel M. T. Chakravarty <[EMAIL PROTECTED]> writes:
>
...
> > >
> > > 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.
>
The opposite, I'd say. In general you cannot know whether you've
got the last reference to an obj or not. So, you will end up
doing the following
stbl <- makeStablePtr fObj
res <- callOut ... fObj ...
deRefStablePtr stbl
return res
But this relies on discipline on the part of the user - do you
want it to mysteriously fail if you second guessed wrongly and
left out the allocation of a stable ptr?
If the answer is no, then what you end up with is requiring that
every ForeignObj is wrapped up as in the above. But why not have
the FFI guarantee this in the first place?
> > 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.
>
How does it fail? The FFI addresses how you pass a fixed set of
types to the outside world. It has no notion of a compound type.
--sigbjorn
