From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: John Wiegley Newsgroups: gmane.emacs.devel Subject: Re: async 1.0 Date: Fri, 22 Jun 2012 16:50:35 -0500 Message-ID: References: <87vcij7rvi.fsf@mithlond.arda> <82d34r8ej9.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1340401845 28731 80.91.229.3 (22 Jun 2012 21:50:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 22 Jun 2012 21:50:45 +0000 (UTC) Cc: Sivaram Neelakantan To: Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 22 23:50:44 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SiBka-0006l9-1y for ged-emacs-devel@m.gmane.org; Fri, 22 Jun 2012 23:50:44 +0200 Original-Received: from localhost ([::1]:57415 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SiBka-0003Al-0y for ged-emacs-devel@m.gmane.org; Fri, 22 Jun 2012 17:50:44 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:47718) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SiBkX-0003Ag-6O for emacs-devel@gnu.org; Fri, 22 Jun 2012 17:50:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SiBkV-0006S5-FT for emacs-devel@gnu.org; Fri, 22 Jun 2012 17:50:40 -0400 Original-Received: from mail-yx0-f169.google.com ([209.85.213.169]:56890) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SiBkV-0006Ro-8i for emacs-devel@gnu.org; Fri, 22 Jun 2012 17:50:39 -0400 Original-Received: by yenr5 with SMTP id r5so2421352yen.0 for ; Fri, 22 Jun 2012 14:50:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:cc:subject:references:mail-followup-to:from:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=2q+ji8jaT0J1t4NjyHViZG4se0Xt8hfZzYnS7sn1XD4=; b=SfHB+82GPHzbYT75K7hRZ6XgboH9lhAuJbmstlIU+cxUA9Fhmq6VeyoHy5J2PYivzS qZ8RDG3/p7Harv9XGbpJjOVpWRGAqZKLgfKOPMlAD2Y7ZdlPvh3Y140ywYixrpOF/ywK 26m/F3zOYsfgjZAJ94j1j4iEIAYxZ7qOuYwLZ33TVf1iPSL30f9t2VLaV3jsfmfQClrQ VQXHOScFdxmGcduWeZiP78mVd3A9qOPncWqn2wnc8RFS86kuNbC2GwOiUInclqz3xlNv lRAGfXmn9sUSN0kfzU4g2YsgpgXQPQNuNcA8zitH7d+l9K52K6c9HgHtBeLwZ0ORQJMs q8Ng== Original-Received: by 10.50.237.71 with SMTP id va7mr3154560igc.6.1340401837265; Fri, 22 Jun 2012 14:50:37 -0700 (PDT) Original-Received: from vulcan.local (c-98-215-105-167.hsd1.il.comcast.net. [98.215.105.167]) by mx.google.com with ESMTPS id z7sm208361igb.3.2012.06.22.14.50.36 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Jun 2012 14:50:36 -0700 (PDT) Original-Received: by vulcan.local (Postfix, from userid 501) id C01AEF0411EC; Fri, 22 Jun 2012 16:50:35 -0500 (CDT) Mail-Followup-To: Emacs developers , Sivaram Neelakantan In-Reply-To: <82d34r8ej9.fsf@gmail.com> (Sivaram Neelakantan's message of "Fri, 22 Jun 2012 22:33:38 +0530") User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.1 (darwin) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.213.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:151093 Archived-At: >>>>> Sivaram Neelakantan writes: > As a lowly user of Emacs, is this going to get into the main branch as I > seem to be doing a lot of stuff in Emacs that makes the wait icon a regular > screen feature? Getting async.el into the main branch can happen next week, if Stefan and RMS approve. But modifying Emacs packages to take advantage of asnynchronicity would require a lot more time and testing. One thing that would make async.el _incredibly_ useful would be a `call/cc' function in Emacs. Then I could write the following: (defun some-complicated-command () (interactive) (async-start/cc (lambda () ... do hard processing in a sub-emacs ...) ;; Instead of being called with just the return value, the ;; finish function is now also called with the result of ;; (call/cc) after invoking the sub-Emacs (lambda (ret cont) (funcall cont))) (message "This processing happens *after* the callback is called.")) The difference here is that right now, `async-start' returns to the *caller* immediately, with finalization code in the callback. If I had `call/cc', `async-start/cc' would return to the *user* immediately. The callback's only job would be to call the continuation, which would resume execution of the stack that has spawned the asynchronous process. The issue this addresses is that right now, if you call `async-start' when call stacks are deep (Gnus, Eshell, etc.), the code has to be made aware that finalization has been moved to a callback function. It essentially has to be "short-circuited", to know that asynchronicity is involved. With continuations, we can push the current runtime stack into a variable, pop back to the Emacs event loop immediately, and then resume that runtime stack once the asynchronous function has finished executing. Stefan/Chong: how hard would this be to add? I'm aware we'd have to move away from reliance on the C stack; but since they were able to make Python stackless, I wonder how hard it would be to make Emacs Lisp the same? John