Re: Guile and ucontext

[Neil Jerram]

Fredrik Tolf <address@hidden> writes:

> Hi list,

Hi Fredrik,

> I'd really like to use Guile in a program I'm writing, but I'm having a
> problem in that I'm using the ucontext calls rather heavily to run a
> great amount of light-weight threads (in only one pthread, that is), and
> it seems that Guile doesn't exactly thrive in that environment.

Interesting problem...

Two vaguely encouraging initial thoughts:

1. On ia64, Guile's exception and continuation logic is already
implemented using setcontext() and getcontext().  (This is done via
some strange redefinitions of setjmp and longjmp; see __scm.h.)  If
you follow through that code, and the things like stack saving and
copying that are done in conjunction with those calls, it may give you
a clear idea of what would be needed to support more general ucontext
switching.

2. If you are happy to be really on the bleeding edge, you could try
using the "bdw-gc-static-alloc" or "boehm-demers-weiser-gc" branch
from Git.  Those branches use the Boehm GC library instead of Guile's
own GC code, and Boehm GC may work better with ucontext switches.

>>From what I can tell from Guile's threads.c, Guile will just record the
> top and bottom of a single stack per pthread, and since I'm switching
> stack pointer between the original stack at the top of the process to
> heap-allocated stacks, it would try to mark data words from almost the
> entire process space when GC'ing.

I'm afraid I don't understand this.  Are you changing the whole stack
of an existing thread?

> Is this correct, or is it perhaps possible to make Guile understand my
> stack switching as it is? Or is it, perhaps, possible to turn off
> marking of words on the stack?

Not by build or runtime configuration, no.  (Stack marking is a pretty
fundamental concept.)

> (I won't be keeping very many SCM pointers there that aren't
> reachable from scheme variables anyway, and if I do, I think I can
> protect them manually) If it isn't, I guess I'll have to patch Guile
> to cope with multiple stacks, but I'd rather spare myself that work
> unless it's necessary.

Dive in!  If you grep for "scm_mark_locations", that will show you all
of the memory regions that get scanned for GC, including thread
stacks.

Regards,
        Neil