Email list hosting service & mailing list manager


Re: when GC is permitted Jim Blandy 08 Jan 2004 01:43 UTC

Tom Lord <xxxxxx@emf.net> writes:
>     >    However, I would like to be able to use Scheme as an extension
>     >    language for existing C programs that use multiple system threads, and
>     >    I would like SRFI-50 to provide what I need to implement the C/Scheme
>     >    glue for this.
>
>     > To be useful in such a situation there would need to be a way to exit
>     > and then re-enter the implicit critical section surrounding C calls.
>
> What are you talking about?  I can imagine many interpretations of
> what you're saying but none that make your statement both true and
> significant.

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

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

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