K>>> To be useful in such a situation there would need to be a way to exit
    K>>> and then re-enter the implicit critical section surrounding C calls.

    L>> What are you talking about?  I can imagine many interpretations of
    L>> what you're saying but none that make your statement both true and
    L>> significant.

    B> What he wrote seems clear enough.  If SRFI-50 provided a begin/end
    B> pair of functions that indicated that the calling thread was holding
    B> no references to heap objects, then collection wouldn't need to wait
    B> for threads in that state.  One could call the 'begin' function when
    B> beginning use of SRFI-50 functions, and the 'end' function when
    B> leaving the module.

    B> In the scenario I sketched above, as long as one always called the
    B> 'end' function before returning to the main application's code,
    B> threads running such code wouldn't block GC indefinitely.

    B> I think it's still too fragile, and you still have the first-class
    B> code / second-class code sort of distinction which I don't like, but
    B> it's sufficient.

Interesting reading.  Doesn't seem right in the senses that such
functions would add almost no new semantics to the draft and that it
doesn't explain the "re-" in "re-enter".

-t