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.
[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 <jimb@xxxxxxxxxx> 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