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.
My initial post, as written, does say that explicitly freed references solve the thread-related problems with SCHEME_EXTRACT_VALUE_POINTER and SCHEME_EXTRACT_STRING. But that's not right; as described, references don't have anything to do with that problem. I inserted the paragraph about SCHEME_EXTRACT_* after I'd written everything else, and didn't notice that I'd changed the antecedent of "this problem" in the next paragraph. Here is how that section should read: 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