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.
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