[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: thread-safe interfaces [correction]
[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: