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]

Re: Selectable Garbage Collection?


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