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.el: A simple asynchronous framework for Emacs Date: Tue, 19 Jun 2012 15:44:28 -0500 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1340138733 19668 80.91.229.3 (19 Jun 2012 20:45:33 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 19 Jun 2012 20:45:33 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 19 22:45:33 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 1Sh5Iq-0002tD-Le for ged-emacs-devel@m.gmane.org; Tue, 19 Jun 2012 22:45:32 +0200 Original-Received: from localhost ([::1]:60952 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sh5Iq-00067b-Ky for ged-emacs-devel@m.gmane.org; Tue, 19 Jun 2012 16:45:32 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:60524) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sh5In-00066n-Vm for emacs-devel@gnu.org; Tue, 19 Jun 2012 16:45:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sh5Im-00049t-7b for emacs-devel@gnu.org; Tue, 19 Jun 2012 16:45:29 -0400 Original-Received: from mail-gg0-f169.google.com ([209.85.161.169]:56185) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sh5Im-00049U-0j for emacs-devel@gnu.org; Tue, 19 Jun 2012 16:45:28 -0400 Original-Received: by ggm4 with SMTP id 4so5844934ggm.0 for ; Tue, 19 Jun 2012 13:45:25 -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:message-id :user-agent:mime-version:content-type; bh=d0NweWBSV7H5hEQSyNivEPf0aipFwx5FH257LM7OMp4=; b=QstRrJLLOftWE/BNzIaCvK8ti1En2RDnrfzEdn1FsTlEQOjlE5Jf0Xp/09yQMFOFUp mT5hgEb8kk82zvSZ5nbhQ/8O7JVmf+IFWJldk88KV4WrTBw3kmzXNhsIr6CTQf02DTOt y2ZcEfWMu4grC/b1i+alQp5/Ju0Ft/EmPldKXO3dG/0V2Y4kHxERaozjr7cd+LFkrUWo KiatErnB6ryUgqpZiSsUwWQCqMT3NhuoA8uCpZT5U4eto6rqb1d671pAIcYzOFiATdQy ZcUPBlqhsuhSrm/EQDiDer2lljCmEFsup+vQx8UdvoBEPDpFqDMLa8GM9O/ylIsn3Acq 8NIA== Original-Received: by 10.42.130.199 with SMTP id w7mr8909968ics.23.1340138725251; Tue, 19 Jun 2012 13:45:25 -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 k6sm23303241igw.14.2012.06.19.13.45.23 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jun 2012 13:45:24 -0700 (PDT) Original-Received: by vulcan.local (Postfix, from userid 501) id DD03CEFBD913; Tue, 19 Jun 2012 15:44:28 -0500 (CDT) Mail-Followup-To: emacs-devel@gnu.org 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.161.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:151032 Archived-At: >>>>> Stefan Monnier writes: >> This will execute the lambda (which must *not* be byte-compiled -- in other >> words, don't use `function' or #') in a child Emacs asynchronously. > Can you explain why it can't be byte-compiled? Because it becomes an un-`read'-able value if prin1'd. > Also, I'd guess that your package could be improved if Emacs provided > a `fork' primitive, right? You bet. However, I would almost never want to fork the whole environment. I would want the child to end up with nil values for: timer-list timer-idle-list kill-emacs-hook And perhaps even a few others, if there are post-command-hooks that might persist data, for example. Plus, it would make no sense to fork over the windows and frames, as the child would be headless; nor the process list. And what about unmodified buffers, and file locks being held by the parent? It would probably be better if `fork' took a conservative approach, requiring me to supply a predicate to match the variables and buffers I wanted to end up in the child. John