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] |
Mikael Djurfeldt <mdj@nada.kth.se> wrote: > > 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! [cut] > 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. Better (IMHO) to leave the "high level" gh_ interface the same and have each gh_ function call a get_specific() in order to obtain the current thread context. Maybe at the scm_ level it'd be all right to add fn params. Anyway, what's to prevent someone from passing in the wrong context pointer? -John