[This correction was noted in another message already, but I'm
reposting it as a reply to my original message so it'll be attached to
the right thread.  Sorry.]

The post this message replies to contained a last-minute edit which
made the main argument make no sense.

A JNI-style reference-based interface does not address the limitations
of SCHEME_EXTRACT_VALUE_POINTER and SCHEME_EXTRACT_STRING, as the
previous message suggests.  They do allow the collector to accurately
find mutator threads' references to heap objects at any time.

I should have written:

Jim Blandy <xxxxxx@redhat.com> writes:
> The proposal states that "the garbage collector may run whenever an
> object is allocated in the heap."  In context, I think that really
> means, "the garbage collector may *only* run..."  In a multi-threaded
> context, I think this must mean that the collector may only run when
> any thread allocates an object on the heap, which isn't much of a
> restriction at all; the collector can run at any time.
>
> If that is so, then the way the proposal suggests C code should refer
> to Scheme values makes it impossible for the collector to find and
> relocate heap references.  The C compiler may have stashed them
> anywhere, in disguised forms, and it is probably unwilling to tell you
> much about where they are at any given time.
>
> The Java Native Interface handles this problem by essentially
> forbidding C code from ever referring directly to a GC'd object.
> Instead, C code may only handle "references" to GC'd objects.  This
> restriction is enforced by the type system.  References are explicitly
> freed objects, which is way people are accustomed to working in C.
> And because the explicit-free model is a complete pain in the neck,
> the JNI tries to ease that pain by segregating references into "local"
> and "global", where "local" references are freed for you at a
> convenient time.
>
> Another issue is that, if a collection could occur at any time, the
> values returned by macros like SCHEME_EXTRACT_VALUE_POINTER and
> EXTRACT_STRING can't be trusted long enough to be useful.  This can
> be solved in various ways; one idea is sketched in:
>
>   http://sources.redhat.com/ml/guile/1999-01/msg00093.html