[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Guile and ucontext
Re: Guile and ucontext
Sat, 16 May 2009 13:07:14 +0100
Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
Fredrik Tolf <address@hidden> writes:
> Hi list,
> 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.
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
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
> (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