On Sun, 18 Jan 2004, Tom Lord wrote:

>
>
>    > From: bear <xxxxxx@sonic.net>
>
>    > > 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
> data?

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.

				Bear