From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Tom Lord Newsgroups: gmane.lisp.guile.devel Subject: Re: Threads and asyncs Date: Mon, 2 Sep 2002 15:24:34 -0700 (PDT) Sender: guile-devel-admin@gnu.org Message-ID: <200209022224.PAA07962@morrowfield.regexps.com> References: <87it1oglmq.fsf@zagadka.ping.de> <200209022124.OAA07625@morrowfield.regexps.com> <87bs7ggiss.fsf@zagadka.ping.de> NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1031004707 30470 127.0.0.1 (2 Sep 2002 22:11:47 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 2 Sep 2002 22:11:47 +0000 (UTC) Cc: guile-devel@gnu.org, guile-user@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 17lzQ9-0007vL-00 for ; Tue, 03 Sep 2002 00:11:45 +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 17lzRa-0000FX-00; Mon, 02 Sep 2002 18:13:14 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17lzR4-00006Q-00 for guile-devel@gnu.org; Mon, 02 Sep 2002 18:12:42 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17lzR0-000064-00 for guile-devel@gnu.org; Mon, 02 Sep 2002 18:12:41 -0400 Original-Received: from 1cust11.tnt13.sfo8.da.uu.net ([63.10.241.11] helo=morrowfield.regexps.com) by monty-python.gnu.org with esmtp (Exim 4.10) id 17lzQz-00005w-00; Mon, 02 Sep 2002 18:12:38 -0400 Original-Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id PAA07962; Mon, 2 Sep 2002 15:24:34 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Original-To: mvo@zagadka.ping.de In-Reply-To: <87bs7ggiss.fsf@zagadka.ping.de> (message from Marius Vollmer on 02 Sep 2002 23:53:23 +0200) 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:1226 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1226 > I don't think they are simpler or faster. Plausibly thread-independent asyncs are faster, at least by a few instructions, since global data is less expensive to access than thread-specific data. Against that, I suppose, are locking issues. My concern is not only how it works out in the current implementation, as an incremental change -- but also how it works out as a candidate feature of an implementation independent Scheme API. While the performance loss may be negligable in Guile, it might not be in other plausible implementations. There's always wiggle room. Nobody has said that it's Guile's job to solve the Scheme API problem. You can (and have) just declare "that doesn't matter for Guile's aims" and then there is no basis for disagreement. > Is there no use for thread-independent system-asyncs? I can't think of any, right now. Any short computation that needs to be invoked asynchronously (say, perhaps, driven by a timer) is a candidate. One can imagine efficient I/O working this way, for example; or simple animation of some sort in a GUI. Suppose we have a multi-CPU system and an application with roughly one thread per CPU -- being able to schedule tasks that float to the next available CPU seems obviously useful, to me. -t _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel