> 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?

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).

In a portable FFI, the issue is especially nasty because you can
(_probably_) have at most the mere possibility of sharing and only
read-only access -- within an implementation, you have to solve the
same issues but with sharing guarantees and mutability.  (I say
"_probably_" because I can imagine wackiness like an FFI that permits
sharing to be simulated in implementations that can't permit it
direcctly but that seems pretty excessive to me.)

    > >I think we've cooked down the implications of some FFI design space
    > >parameters to this:
    > >
    > >
    > >   Parameter			Restricting		Resulting
    > >				Choice			Restriction
    > >   ----------------------------------------------------------------
    > >
    > >   A. GC only at certain	Yes		Aynchronous threads may
    > >      C sequence points?			not cause GC;  signal
    > >                                        	handlers may not cause
    > >                                                GC
    > >
    > >   B. Scheme values		Yes		Requires A
    > >      repesented as
    > >      C rvalues?
    > >
    > >   C. Barrierless reads		Yes		Certain incremental GC
    > >      and writes to Scheme			techniques prohibited;
    > >      locations?				Requires A and B

    > I would say that this is an excellent summary.  Barrierless reads (C)
    > are 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.

    > >Supposing that your choice is (A+B) or (A+B+C), then there's a new
    > >parameter which is what you're asking Ray about:

    > >
    > >   D. Some FFI functions may	Yes		Scheme types not extensible
    > >      not cause GC                              in Scheme;
    > >                                                Some scheme types or procedures
    > >                                                not implementable in terms
    > >                                                of others;
    > >                                                (Implies A, of course)

    > I think you've hit the nail on the head here.

Thanks.  It's helpful to me to have second opinions like that -- I do
sometimes worry that I've missed something somewhere.

-t