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: why asyncs were created Date: Mon, 2 Sep 2002 15:55:31 -0700 (PDT) Sender: guile-devel-admin@gnu.org Message-ID: <200209022255.PAA08110@morrowfield.regexps.com> NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1031006554 1870 127.0.0.1 (2 Sep 2002 22:42:34 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 2 Sep 2002 22:42:34 +0000 (UTC) Cc: lord@morrowfield.regexps.com 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 17lztx-0000U3-00 for ; Tue, 03 Sep 2002 00:42:33 +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 17lzvU-0003Ne-00; Mon, 02 Sep 2002 18:44:08 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17lzux-0003IA-00 for guile-devel@gnu.org; Mon, 02 Sep 2002 18:43:35 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17lzuv-0003Hy-00 for guile-devel@gnu.org; Mon, 02 Sep 2002 18:43:35 -0400 Original-Received: from 1cust167.tnt13.sfo8.da.uu.net ([63.10.241.167] helo=morrowfield.regexps.com) by monty-python.gnu.org with esmtp (Exim 4.10) id 17lzuu-0003Hu-00; Mon, 02 Sep 2002 18:43:33 -0400 Original-Received: (from lord@localhost) by morrowfield.regexps.com (8.9.1/8.9.1) id PAA08110; Mon, 2 Sep 2002 15:55:31 -0700 (PDT) (envelope-from lord@morrowfield.regexps.com) Original-To: guile-devel@gnu.org, guile-user@gnu.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:1228 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1228 Since there is talk of removing the async abstraction, I thought I would mention, just to provide information, why it was added in the first place. The kernel has a built-in facility for interrupting a process, pushing a new call frame onto a stack, and invoking some function -- handling a return or longjmp from that function specially -- and treating interrupts specially while that function runs. That's a useful facility, but not one that has a unique natural mapping into RnRS scheme. Asyncs were designed to model that facility while reconciling it with the restrictions against executing arbitrary Scheme code at arbitrary times. The farther Scheme signal handling is removed from some abstraction like asyncs, the less well the corresponding kernel facility is reflected in the language. Having designed system asyncs, user-defined asyncs were, I felt, a natural and easy generalization. -t _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel