From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.lisp.guile.devel Subject: Re: Threads and asyncs Date: Wed, 4 Sep 2002 18:46:16 -0500 Sender: guile-devel-admin@gnu.org Message-ID: <02090418461625.19624@locke.free-expression.org> References: <87it1oglmq.fsf@zagadka.ping.de> <87u1l73ls1.fsf@raven.i.defaultvalue.org> <02090220483420.19624@locke.free-expression.org> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1031183385 32715 127.0.0.1 (4 Sep 2002 23:49:45 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 4 Sep 2002 23:49:45 +0000 (UTC) Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17mju3-0008VW-00 for ; Thu, 05 Sep 2002 01:49:44 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17mjvZ-0002Bv-00; Wed, 04 Sep 2002 19:51:17 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17mjul-00022g-00 for guile-devel@gnu.org; Wed, 04 Sep 2002 19:50:27 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17mjuj-00022U-00 for guile-devel@gnu.org; Wed, 04 Sep 2002 19:50:26 -0400 Original-Received: from julesburg.uits.indiana.edu ([129.79.1.75]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17mjui-00022Q-00 for guile-devel@gnu.org; Wed, 04 Sep 2002 19:50:24 -0400 Original-Received: from stjoseph.uits.indiana.edu (stjoseph.uits.indiana.edu [129.79.1.78]) by julesburg.uits.indiana.edu (8.12.1/8.12.1/IUPO) with ESMTP id g84NoLeP002036 for ; Wed, 4 Sep 2002 18:50:21 -0500 (EST) Original-Received: from locke.free-expression.org (dial-123-80.dial.indiana.edu [156.56.123.80]) by stjoseph.uits.indiana.edu (8.12.1/8.12.1/IUPO) with SMTP id g84NoLRL006173 for ; Wed, 4 Sep 2002 18:50:21 -0500 (EST) Original-To: guile-devel@gnu.org X-Mailer: KMail [version 1.2] In-Reply-To: <02090220483420.19624@locke.free-expression.org> Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:1278 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1278 On Monday 02 September 2002 20:48, Lynn Winebarger wrote: > As for the rest, I think we should make C functions > declare themselves as primitives that never call Scheme, > and "other", that might call eval. The first could use some > fixed "scratch" stack space, the others should get a freshly > allocated stack (whose size they declare through snarfage > or somesuch). The interpreter could then analyze the > scheme code to find regions "between" call/cc's that could > use some fixed stack. Call/cc's allocate a fresh Scheme > stack for the "next" block of code that gets executed. I believe I can be clearer on this now. Let's say we're doing some computation on stack A with frames A1 - A50, recalling that primitives (whether foreign or internal) have their own "scratch" stack, and non-primitive foreign functions get a freshly allocated stack; so that A really contains only frames generated by eval. Now, let's say we see a call/cc for the first time at A50, so we allocate another stack and set its continuation to the top of this one. Now, after returning from that call (if/when that happens) any subsequent stack using calls get their own stack space, with a continuation into A wherever it left from. For example, let's say I returned, and then descended the stack to frame A40, then called myota (defined in Scheme). Then a new stack C (since B was allocated for the first call/cc) gets allocated with its continuation pointer to A40 (and maybe to A's bottom to make the GC's job easier). This amounts to lazy allocation of continuations, whereas a straightforward implementation where each stack frame is freshly allocated will result in lots of garbage, this should result in only as much continuation garbage as absolutely necessary. Call/cc should be reasonably fast, and current C programs can be grandfathered in by assuming non-primitivity, and only a minimal amount of declarative work for those who want GUILE to know which of their functions are primitives. Of course, there should also be some way to return unused space off the top of the stack to the GC. The garbage collector could be made to recognize when the top part of the stack is no longer referenced an can be reused. Did that make sense? Anyone see a hole in it? Lynn _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel