[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Guile and ucontext

From: Neil Jerram
Subject: Re: Guile and ucontext
Date: Sat, 16 May 2009 13:07:14 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]