Re: when GC is permitted Tom Lord 08 Jan 2004 04:21 UTC
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
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".