Tom Lord <xxxxxx@emf.net> writes:
>     > From: Jim Blandy <xxxxxx@redhat.com>
>
>     > The points I made in the very first post to this SRFI's
>     > discussion list still apply, though --- GCPRO cannot be made to
>     > work in multi-threaded contexts.
>
>
> I think that that's overstated.
>
> SRFI-50 does need some work (perhaps nothing more than more precise
> specification) to support threads, and does need some work on the GC
> interface, but a GCPRO-technique can still work and is arguably
> preferable to a JNI-style reference-object technique.
>
> You expressed concern about the GC relocating objects addressed by
> pointers returned from SCHEME_EXTRACT_VALUE_POINTER and
> SCHEME_EXTRACT_STRING.  These issues are solvable by any of a variety
> of means, including:

Yes, the EXTRACT issues aren't critical.  But the thread-related
problems with GCPRO that I don't see how to solve are those created by
the user's compiler rearranging code that operates directly on heap
references.  The compiler is free to make copies of heap references in
registers where a copying GC can't find them to update them.

The general view is like this: the GCPRO'd variables are inescapably a
data structure that is shared between the mutator thread that owns the
stack frame and some other collecting thread out there.  But there's
no opportunity for the API implementation to do the needed
synchronization.

The only way I can see to save GCPRO is to forbid collection except
when every thread is at a "safe point".  In other words, you
reintroduce the restriction that "collection may only happen in calls
that do allocation", by saying that *every* thread must be in a
specially designated call.

I'm pretty uncomfortable with that.  Especially in a C/Scheme API,
one of whose primary goals is to interface with libraries written by
third parties.