From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.user Subject: Re: Guile and ucontext Date: Sat, 16 May 2009 13:07:14 +0100 Message-ID: <87ab5dxnd9.fsf@arudy.ossau.uklinux.net> References: <1242266987.6770.5.camel@pc7.dolda2000.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1242475740 17126 80.91.229.12 (16 May 2009 12:09:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 16 May 2009 12:09:00 +0000 (UTC) Cc: guile-user@gnu.org To: Fredrik Tolf Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sat May 16 14:08:53 2009 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1M5IhB-0005vd-B9 for guile-user@m.gmane.org; Sat, 16 May 2009 14:08:53 +0200 Original-Received: from localhost ([127.0.0.1]:43039 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M5IhA-0005hW-Fw for guile-user@m.gmane.org; Sat, 16 May 2009 08:08:52 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M5Ifk-0005gn-Lj for guile-user@gnu.org; Sat, 16 May 2009 08:07:24 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M5Ife-0005f7-AM for guile-user@gnu.org; Sat, 16 May 2009 08:07:22 -0400 Original-Received: from [199.232.76.173] (port=53771 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M5Ifc-0005er-Rg for guile-user@gnu.org; Sat, 16 May 2009 08:07:17 -0400 Original-Received: from mail3.uklinux.net ([80.84.72.33]:34289) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M5Ifc-0004SV-7P for guile-user@gnu.org; Sat, 16 May 2009 08:07:16 -0400 Original-Received: from arudy (host86-145-50-237.range86-145.btcentralplus.com [86.145.50.237]) by mail3.uklinux.net (Postfix) with ESMTP id 4DE911F665D; Sat, 16 May 2009 13:07:15 +0100 (BST) Original-Received: from arudy.ossau.uklinux.net (arudy [127.0.0.1]) by arudy (Postfix) with ESMTP id B506738013; Sat, 16 May 2009 13:07:14 +0100 (BST) In-Reply-To: <1242266987.6770.5.camel@pc7.dolda2000.com> (Fredrik Tolf's message of "Thu\, 14 May 2009 04\:09\:46 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:7305 Archived-At: Fredrik Tolf 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