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 20:45:26 -0500 Sender: guile-devel-admin@gnu.org Message-ID: <02090420452627.19624@locke.free-expression.org> References: <87it1oglmq.fsf@zagadka.ping.de> <02090418461625.19624@locke.free-expression.org> <200209050020.RAA18890@morrowfield.regexps.com> 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 1031190510 14522 127.0.0.1 (5 Sep 2002 01:48:30 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 5 Sep 2002 01:48:30 +0000 (UTC) Cc: guile-devel@gnu.org 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 17mlky-0003m6-00 for ; Thu, 05 Sep 2002 03:48:28 +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 17mlmY-0000FQ-00; Wed, 04 Sep 2002 21:50:06 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17mlm6-0000Cj-00 for guile-devel@gnu.org; Wed, 04 Sep 2002 21:49:38 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17mlm3-0000CX-00 for guile-devel@gnu.org; Wed, 04 Sep 2002 21:49:38 -0400 Original-Received: from julesburg.uits.indiana.edu ([129.79.1.75]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17mlm3-0000CT-00 for guile-devel@gnu.org; Wed, 04 Sep 2002 21:49:35 -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 g851nVeP018014; Wed, 4 Sep 2002 20:49:31 -0500 (EST) Original-Received: from locke.free-expression.org (dial-118-60.dial.indiana.edu [156.56.118.60]) by stjoseph.uits.indiana.edu (8.12.1/8.12.1/IUPO) with SMTP id g851nVRL010815; Wed, 4 Sep 2002 20:49:31 -0500 (EST) Original-To: Tom Lord X-Mailer: KMail [version 1.2] In-Reply-To: <200209050020.RAA18890@morrowfield.regexps.com> 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:1288 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1288 On Wednesday 04 September 2002 19:20, Tom Lord wrote: > > so that A really contains only frames generated by eval. > > > Why do you need more than one such frame (on a C stack) per Scheme > thread (without calls out to "non-primitive foreign functions")? > > With only one C frame, call/cc can be _really_ fast and I think you > can go in this direction without trashing eval's performance. The problem with this is that it requires really fast garbage collection. Guile's commitment to conservative collection can present a serious problem in this regard. WIth this proposal, continuations that do not have a reference after the first execution (i.e. no call/cc) will be "garbage collected" simply by popping the stack. New continuations get allocated only and exactly when needed. Indeed, I think it can the proposal can be completely characterized as merely an allocation strategy for heap-allocated stack frames, and nothing more. Now that I think about it, I believe it will do strictly less work than applying general GC to individual activation records. (that is, whatever general GC the interpreter is using - I don't make the claim for this method plus Guile's GC versus unfettered frame allocation + some other GC; rather this method plus GC versus unfettered frame allocation plus that same GC). > But, loosely speaking -- the idea of mixing special stacks for > classical C with stacks just for Scheme seems to me to be a useful > one, and, if the interfaces in Guile are suitably cleaned up, a way to > evolve forward. > > It's a drag that the work on Guile debugger support has thwarted > simply dropping in the faster eval from recent SCMs -- but you could > leapfrog over that with a stackless eval. Is all the thread hair in SCM as well? > > and current C programs can be grandfathered > > One language implementor I met made a big fuss over amdhal's law -- > which has the implication for Guile that cleaning up various apis > (internal and external) should be a big priority. Ok, I give up, how do the two relate exactly? > I sort of agree, except that there's a trap there: which is to build > up abstractions for abstraction sake in areas where, really, there are > right and wrong answers, with the right answers requiring less than > fully general abstractions (and, in fact, being somewhat incompatible > with fully general abstractions). It's hard to determine the correct answer without knowing what the question is. > > Did that make sense? Anyone see a hole in it? > > IM*H*O: nothing major. Keep going in that direction. But you're > nearing the frontier between my experience and my speculation, so I'll > shut up now. It's beyond my experience as well, but I think it is correct. After getting my MCSI's syntax-case working, I might use it to experiment with this idea. Lynn * Is "metacircular scheme interpreter" a common enough phrase (in the scheme community) to be recognizable as an acronym? _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel