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 17:02:29 -0500 Message-ID: References: <87vcij7rvi.fsf@mithlond.arda> <87r4t7sepa.fsf@gmx.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1340402616 1450 80.91.229.3 (22 Jun 2012 22:03:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 22 Jun 2012 22:03:36 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 23 00:03:35 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 1SiBwz-0004q9-NM for ged-emacs-devel@m.gmane.org; Sat, 23 Jun 2012 00:03:33 +0200 Original-Received: from localhost ([::1]:58882 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SiBwz-0004TT-K8 for ged-emacs-devel@m.gmane.org; Fri, 22 Jun 2012 18:03:33 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:34762) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SiBwx-0004TM-90 for emacs-devel@gnu.org; Fri, 22 Jun 2012 18:03:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SiBwv-0000c3-DZ for emacs-devel@gnu.org; Fri, 22 Jun 2012 18:03:30 -0400 Original-Received: from mail-yw0-f51.google.com ([209.85.213.51]:57402) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SiBwv-0000bt-69 for emacs-devel@gnu.org; Fri, 22 Jun 2012 18:03:29 -0400 Original-Received: by yhnn12 with SMTP id n12so2018971yhn.38 for ; Fri, 22 Jun 2012 15:03:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:references:mail-followup-to:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=e/+rsWycznriPLQho8aVd871v/C03LUpmDlaaQf+qAg=; b=OwVbQTzCecAw7FhRQ9QXV10cszH4ngyy1SsWCYjCTpFUfciHq1WtzkT4kismiirCoZ hrOQKaY+5ef8RfUVQ2GkNOScSVcSyC0LW+/3ML922Fpf0cH6wspg9qm/PM23nCPYh04/ Lpkf++YSQXwbITKOO0r9a7XVW8lTATyXyMYrEqocpbO5J6VVoojycUhQ4plNQ0LOQYn5 VddNbI5pGY1wqsIpFYWBRCnxP6YQRJuG4LjxllT10FFH8PMnfBfoENgQOFhgN6JJGXiA Cv+8zhjtziJKY62GH9+zGQ9Ob9EkjX2KmLR3B6X55Jx54N8QjisRg/F5YGz+J9Nbb+9A 078A== Original-Received: by 10.50.237.71 with SMTP id va7mr3173465igc.6.1340402607363; Fri, 22 Jun 2012 15:03:27 -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 z3sm231848igc.7.2012.06.22.15.03.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Jun 2012 15:03:24 -0700 (PDT) Original-Received: by vulcan.local (Postfix, from userid 501) id 036E2F041DF9; Fri, 22 Jun 2012 17:02:29 -0500 (CDT) Mail-Followup-To: emacs-devel@gnu.org In-Reply-To: <87r4t7sepa.fsf@gmx.de> (Michael Albinus's message of "Fri, 22 Jun 2012 14:39:45 +0200") 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.51 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:151094 Archived-At: >>>>> Michael Albinus writes: > Or you keep the Emacs daemons running in the background, waiting for new > tasks. Communication could be via D-Bus (queued services). But I have no > idea, how much it would improve reactiveness. > > And it wouldn't run on all platforms Emacs supports. And it introduces state bugs, which would be insane to debug, since presently there is no a way to debug the child Emacs. I'm having a hard time even getting stack traces from the point of failure (a condition-case handler gives you the backtrace for the handler, not the error's origin. This may need new functionality in Emacs to pass the trace as part of the error data). I've been talking with someone else who is interested in creating a Swank backend for Elisp that would make such debugging possible, but even then it's not something I'd want to rely on after only the 20th `async-start' call failed, though all the prior ones had succeeded... The startup cost for async Emacs is currently dwarfed by the size of the tasks I'm using it for. If your async job is only running for a few hundred milliseconds, I would say don't use async.el for that job, rather than trying to optimize that case. John