This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
Tom Lord <lord@xxxxxxx> writes: > > From: Jim Blandy <jimb@xxxxxxxxxx> > > > 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.