This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
"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