Re: Selectable Garbage Collection?

[Mikael Djurfeldt <mdj@nada.kth.se>]

"Scott C. Gray" <gray@voicenet.com> writes:

> Second, what I would *really* like to do is to give each thread 
> its own instance of a guile interpreter, but unfortunately
> it does not seem that guile supports the concept of an
> interpreter context (similar to what TCL has). Now, in
> the current release of the threading library I am using
> (Sybase Open Server), there are hookpoints that I can use
> to, say, swap out name spaces within the interpreter
> between context switches, but in the upcoming releases,
> native threading (real honost-to-god lwp's) are supported
> so this won't work any more since there will be muliple 
> simultaneous name spaces).  Any suggestions, or do I just 
> need to live with a shared name space--assuming that I 
> can solve the first problem, above.

I don't know what other people have told you, but I'm afraid that
there currently are some fundamental problems with using Guile from
several OS threads: It is simply not possible.

There are two problems:

1. The GC must know the top and the bottom of the stack in order to be
   able to do GC.  You're already familiar with this problem, but I'll
   reiterate it anyway: If thread 1 bootstraps Guile by calling
   gh_enter or scm_boot_guile, the GC will be aware of the bottom of
   stack 1.  If we get a context switch to thread 2 and thread 2 calls
   Guile we get three problems: 1. Depending on where in memory the
   stack of thread 2 has been allocated the evaluator may or may not
   immediately report a stack overflow error.  2. Since Guile hasn't
   been informed about stack 2, objects handled by thread 2 aren't GC
   protected.  Nor are the objects they refer to.  3. Since Guile
   still believes that it is in thread 1, it will regard the top of
   stack 2 as the top of stack 1 and objects on stack 1 aren't
   guaranteed to be protected either!

2. If a context switch occurs when inside a Guile call, Guile may be
   interrupted inside a critical section which will very likely lead
   to a crash when the new thread invokes GC.

The first problem could, in principle, be handled by supplying a
pointer to a "thread context" with each call to the Guile library.  We
would need to write a "twin set" of the gh calls which has this extra
argument.

The second problem is much more difficult since it requires rewriting
of the critical sections in Guile and some additional internal
resource management code.  This *will* be done at some time when we
add support for OS threads, but it is not top priority.

Therefore I would say that currently Guile can't be used from multiple
threads.  Guile should only be called from *one* OS thread.  (You may
be able to let the other threads use the Guile resource *through* this
thread though...)

/mdj