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: Mon, 25 Jun 2012 18:54:53 -0500 Message-ID: References: <87vcij7rvi.fsf@mithlond.arda> <82d34r8ej9.fsf@gmail.com> <87r4t4zr9l@ch.ristopher.com> <87wr2vzbm7@ch.ristopher.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1340668562 17181 80.91.229.3 (25 Jun 2012 23:56:02 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 25 Jun 2012 23:56:02 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 26 01:56:00 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 1SjJ8R-0000ye-KY for ged-emacs-devel@m.gmane.org; Tue, 26 Jun 2012 01:55:59 +0200 Original-Received: from localhost ([::1]:46323 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SjJ8R-0006Rx-BG for ged-emacs-devel@m.gmane.org; Mon, 25 Jun 2012 19:55:59 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:35297) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SjJ8O-0006Rq-6J for emacs-devel@gnu.org; Mon, 25 Jun 2012 19:55:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SjJ8M-0001y8-0a for emacs-devel@gnu.org; Mon, 25 Jun 2012 19:55:55 -0400 Original-Received: from mail-gh0-f169.google.com ([209.85.160.169]:47823) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SjJ8L-0001y1-OU for emacs-devel@gnu.org; Mon, 25 Jun 2012 19:55:53 -0400 Original-Received: by ghrr18 with SMTP id r18so4070848ghr.0 for ; Mon, 25 Jun 2012 16:55:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:message-id:references:mail-followup-to:date :in-reply-to:user-agent:mime-version:content-type; bh=g27TUuuFdBY+oM3Mx/5TsvrC/oxPMOW6jZ62rY66qwM=; b=rhtWp7iDo54CJsBeOrVph7fiU/4at8po8trb4BcVy5YfEmMimpVpNpBBu9QbK6LrOV FDDCyALH8sopbeHARWk5IJ+PoPibkvN5T4ULMmDF3Ox+pevOG1G+fS8rIs1wtZuYMiy4 Yyf7PGyVjMdvBkiPchbrlEUJlz+JDAw+ADJX71e2+DRLf/safZvje3uCNrEIQ8FCVrTF h2y15YKyTWPi5+pbkmIaDguxuDKlJd+i+lP3OuTJuDijxzlWZWQUYEitx3VMaGPGfnht 0+MLtl7nq8Xj3FG715pQLyA5f4O5JoRfmQiTXExKcaJ0AYTI+OkBujWyL4wz5yJqfrC7 Inmw== Original-Received: by 10.50.158.168 with SMTP id wv8mr9546185igb.11.1340668550985; Mon, 25 Jun 2012 16:55:50 -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 nh8sm758783igc.1.2012.06.25.16.55.49 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jun 2012 16:55:50 -0700 (PDT) Original-Received: by vulcan.local (Postfix, from userid 501) id 2FA06F0C5778; Mon, 25 Jun 2012 18:54:53 -0500 (CDT) Mail-Followup-To: emacs-devel@gnu.org In-Reply-To: <87wr2vzbm7@ch.ristopher.com> (Christopher Schmidt's message of "Mon, 25 Jun 2012 15:53:39 +0100 (BST)") 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.160.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:151165 Archived-At: >>>>> Christopher Schmidt writes: >>> Other than that, GNU Emacs has excellent asynchronous process and network >>> facilities already. Why not use them? >> >> And these would be? I'm not aware of any core service that lets me >> asynchronously call lambdas. > I do not like that you snipped context out of my quotes. I really am very sorry if I dropped your context. I didn't meant to antagonize, just to reduce the length of my reply. > Why do you want complex forms to be called asynchronously out of the context > of the original Emacs process? My core argument for async.el is that certain Emacs primitives, such as `copy-file' and `process-send-region', cannot benefit from the tricks employed by packages like deferred.el. I think deferred.el is an excellent approach to deferred computation: when things don't need to happen right away, they can be interleaved with the user's commands as the interpreter becomes available. But there are cases when Emacs *must* block the main process for minutes at a time (such as copying a 10G file on my local machine). It is these cases that async.el is designed to address. Otherwise, if deferred.el can solve the problem, I think it's preferrable to use that over full asynchronicity. It's easier to debug with it, behavior is less surprising, and backtraces are more revealing. So we actually have many tools in our toolbox. Async.el would just be one more, with its own caveats and gotchas. So far we have: 1. `start-process'. Works great, if you have an external executable to call. `copy-file' cannot be made asynchronous using this primitive alone, as you cannot depend on the existence of "cp" or "copy.exe" on all platforms. 2. Timers. This is how deferred.el and a few other packages give the semblance of asynchronicity: by returning to the caller immediately, and queueing up code to be executed as the interpreter becomes available. 3. Self-hosting (aka async.el), where a child Emacs is spawned to do work on behalf of the parent Emacs. 4. The "concurrency" branch in Emacs Bzr. I'd really like to know more about what's in here, and what problems it creates and solves. Each of the first three has been used many times over, by many packages. Eshell uses #1 to make use of external programs asynchronously; el-get (thanks to Dave Abrahams) used to use #2 to make updates and installs asynchronous; deferred.el is based on #2; #3 is used by elnode and helm, who rolled their own implementations of what async.el does. So async.el does not invent anything new. The same approach (`start-process' of a child Emacs) is currently "out there" and being used. I just wanted to wrap a simple and generalized interface around this practice, to aid in its further use. > The point I was trying to make is that async.el can make development and > actual end-user usage both simpler and harder. Some issues could be avoided > by using non-forking asynchronous I/O in the first place. "A nice > short-term solution with severe long-term consequences." (Now that I looked > up 'severe' in a dictionary, I think it is the wrong term. I wanted to say > that async.el can cause unexpected surprises.) Yes, this is the bane of asynchronicity in general. And perhaps the best argument for why it should always be "opt-in". > Implementing asynchronous smtp on top of smtpmail within 19 LOC is > impressive. No doubt whatsoever. This is a great opt-in feature. You did > not mention opt-in-ness before and to me it was not obvious from the > context, especially because AFAICT dired-async.el unconditionally redefines > dired internals to use async.el. Sorry if I failed to make my position more clear. I want async.el to be available to everyone, but by no means do I want to inflict it on everyone without their consent. I take a very conservative approach to core Emacs changes, since this is a platform people use to get real work done. I _live_ in Emacs; it's core of my professional life. I wouldn't want it to be disrupted any more than I would want to do the same to you. > I am sorry for offending you if that is the case. I have lots of respect > for your work.[1] None taken, Christopher. I'm just a parent defending his little child. :) John