From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: SAKURAI Masashi Newsgroups: gmane.emacs.devel Subject: Re: async.el: A simple asynchronous framework for Emacs Date: Wed, 20 Jun 2012 18:32:06 +0900 Message-ID: <20120620093232.E729C13D2B1@vps1.kiwanami.net> References: <20120620072447.573D613C624@vps1.kiwanami.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Trace: dough.gmane.org 1340184776 2660 80.91.229.3 (20 Jun 2012 09:32:56 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 20 Jun 2012 09:32:56 +0000 (UTC) Cc: emacs-devel@gnu.org To: jwiegley@gmail.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 20 11:32:54 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 1ShHHQ-0000MN-Nh for ged-emacs-devel@m.gmane.org; Wed, 20 Jun 2012 11:32:52 +0200 Original-Received: from localhost ([::1]:58558 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ShHHQ-0005Zy-Mn for ged-emacs-devel@m.gmane.org; Wed, 20 Jun 2012 05:32:52 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:60812) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ShHHJ-0005ZN-Ac for emacs-devel@gnu.org; Wed, 20 Jun 2012 05:32:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ShHHC-000808-FG for emacs-devel@gnu.org; Wed, 20 Jun 2012 05:32:44 -0400 Original-Received: from vps1.kiwanami.net ([182.48.41.71]:22729) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ShHHC-0007zB-5T for emacs-devel@gnu.org; Wed, 20 Jun 2012 05:32:38 -0400 Original-Received: from liza2.kiwanami.net (localhost [127.0.0.1]) by vps1.kiwanami.net (Postfix) with ESMTP id E729C13D2B1; Wed, 20 Jun 2012 18:32:32 +0900 (JST) In-Reply-To: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/23.4 Mule/6.0 (HANACHIRUSATO) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 182.48.41.71 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:151050 Archived-At: At Wed, 20 Jun 2012 03:13:06 -0500, John Wiegley wrote: > : > Looking further, I see that deferred.el and async.el address slightly > different problem domains. For example, `async-start' creates another Emacs > in which to call the lambda, while deferred.el put the lambda on a timer and > runs it in the parent Emacs. This means that if it's a heavy internal > function -- like a `copy-file' of 10 gigabytes -- it will still block Emacs, > am I right? Yes, you are right. A heavy task should be breaked down into small tasks in the deferred.el manner. deferred.el just supports job controlling on the Emacs and avoiding callback hell. Changing notation for async tasks, the async tasks becomes composable. I think the callback style (CPS) is difficult to write and read. > async.el does not use timers, though it seems that `deferred:process' does, > even though it also uses process sentinels. Am I reading that correctly? Yes. deferred.el uses `run-at-time` function as a simple job scheduing. In my experience, I think that the overhead is small enough. I feel the blocking whole Emacs is more inconvenient. -- SAKURAI, Masashi (family, given) m.sakurai@kiwanami.net