[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Couple things...
On Sun, 18 Jan 2004, Tom Lord wrote:
> > From: bear <bear@xxxxxxxxx>
> > > I think "may GC" applies to all entry points.
> > I tend to agree, but this means no live C pointers directly at
> > storage occupied by scheme data.
> You mean such as a C `char *' pointing directly at, say, some string
That's certainly one example.
> If so, no -- that's not what it (necessarily) means. That's a topic
> we haven't taken up much and is slightly tricky, imo. Options to
> consider are the ability for C code to dynamically declare
> GC-excluding regions (within which at most a subset of the FFI is
> available) and the ability to dynamically declare regions during which
> certain objects are "locked" (with, again, limits on what part of the
> FFI is available).
Oy. what you seem to be saying, is that if it doesn't imply that,
then it implies heroic measures of ever-escalating hair.
A copying Garbage Collector can move something. Is the C code
expected to know it's been moved? Or is the act of getting a
pointer to "shared" data supposed to notify the Garbage Collector
to not move that particular object?
Also, there are possibilities like copy-on-write semantics inside
the scheme systems, where >1 variables may share storage until
one of the copies is written to, at which point it gets a new
address. An FFI that tries to write things by using a live
pointer into scheme storage is not going to have the right
effect here if it doesn't execute the hooks that copy-on-write
depends on on the scheme side. An FFI that's unaware of the
fact that the copy it thought it had a pointer to got moved
to a new address when written from the scheme side is going to
mess up subsequent reads.
>> I would say that this is an excellent summary. Barrierless
>> read/write (C) is probably the biggest problem here as far
>> as I'm concerned. I could live with sequence-point GC (A).
> I think that, in general, A alone is the least controversial. But
> another way to view the design space is that if you want an FFI that
> doesn't imply "C", then the seemingly natural choices for that FFI
> also don't imply "A" and aren't consistent with "B".
> In other words -- once you say no to "C", there's no good reason not
> to say no to "A" and "B" too. The strucutre sharing issues _might_
> give a reason to say yes to "A" without implying "B" or "C" -- but
> they shouldn't be exposed in a portable FFI.
I'm pretty much of the opinion that what gets passed back and
forth across the FFI should be values, not pointers. Let the
C code ask what the value of X is when it wants it, or pass a
value back to store in X. It solves all of these problems, I
think, by making it not-matter when GC happens, keeping C code
out of the structure of the scheme heap, and making it impossible
to run into what-does-it-mean problems with shared structure.