> From: Richard Kelsey <xxxxxx@s48.org>

    >> [....]
    > [....] All that is required is that the incremental GC scan the
    > entire root set in a single increment before deciding that it
    > has reached the end of a [trace] cycle.  This is standard practice
    > for incremental GCs.

That's true only if the root set is small enough that it doesn't
exceed the amount work the tracer will want to do in one step.
What may be a common practice is to write implementations in such a
way that the root set is guaranteed to be small -- but that's not the
same thing as what you've said and the difference matters.

If the root set is large, certainly it should be traced in several
steps, using barriers to preserve its invariants.

Absent any further guidance from the FFI spec, I would expect some
programs to register a very large number of locations -- and worse,
locations scattered widely in memory -- using
SCHEME_GC_PROTECT_GLOBAL.  (Why wouldn't I, in a printed circuit board
CAD program, GCPROtect a field of every C structure representing an
edge in a netlist graph?)

And while the C stack (and hence the number of locations protected by
SCHEME_GC_PROTECT) will _usually_ be small and localized, there is
nothing to preclude it being rather large.

In short, the FFI requires a root set of unbounded size and
unrestricted locality:  the common practice of tracing roots in a
single step does not apply here.

The problem goes away if the FFI imposes barriers over GCPROtected
values.

Alternatively, perhaps SCHEME_GC_PROTECT_GLOBAL should simply be
removed from the FFI.  Programs can instead use integer indexes into
some data structure allocated in the Scheme heap, conceptually
allocating and freeing integer addresses to make them coextensive with
the C heap locations they would otherwise pass to
SCHEME_GC_PROTECT_GLOBAL.  The stack would remain an annoyance but, I
admit, a less fatal one.

    > SCHEME_CAR() and SCHEME_SET_CAR() and so forth need to preserve
    > any read or write barriers, of course.

Sure, and that's good.

    >    (You also talk about threads and interruption points related to them
    >    but, of course, that doesn't address truly concurrent threads.)

    > I am not sure what 'truly concurrent' means (parallel execution?).
    > But yes, we chose efficient C execution over allowing the C code
    > to be interrupted at arbitrary points.

Yes that's what I mean.   But in a later message you remark that you
prefer the current FFI over Pika _not_ for efficiency reasons but for
aesthetic reasons.  I'll take that issue up in reply to the later
message but let's here note that you want to make the FFI incompatible
with some kinds of threading (for which hw support is increasingly
popular and cheap) for reasons of syntax, not efficiency.

And, threads aside, there's the issue of asyncronous execution from
signal handlers.   While it's just fine to postpone to a later SRFI
giving FFI-using code hooks into async mechanisms, what you have in
this FFI is an interface that rather severely restricts
implementations that use async execution internally.   And again, the
justification we're down to for that restriction is, apparently,
concern over syntax.

-t