From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [PATCH 06/10] add most lisp-level features Date: Mon, 13 Aug 2012 16:46:54 -0400 Message-ID: References: <87a9y3etto.fsf@fleche.redhat.com> <502467BF.2020301@dancol.org> <87d32u7smb.fsf@fleche.redhat.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1344891053 13446 80.91.229.3 (13 Aug 2012 20:50:53 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 13 Aug 2012 20:50:53 +0000 (UTC) Cc: Daniel Colascione , Emacs discussions To: Tom Tromey Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 13 22:50:51 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 1T11b9-0006rU-49 for ged-emacs-devel@m.gmane.org; Mon, 13 Aug 2012 22:50:51 +0200 Original-Received: from localhost ([::1]:54400 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T11b8-0004eQ-7B for ged-emacs-devel@m.gmane.org; Mon, 13 Aug 2012 16:50:50 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:54266) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T11b3-0004dS-Mz for emacs-devel@gnu.org; Mon, 13 Aug 2012 16:50:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T11ay-0006mv-K5 for emacs-devel@gnu.org; Mon, 13 Aug 2012 16:50:45 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:45373) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T11ay-0006mp-Fu for emacs-devel@gnu.org; Mon, 13 Aug 2012 16:50:40 -0400 Original-Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id q7DKoMw9032443; Mon, 13 Aug 2012 16:50:28 -0400 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 15D7CAE427; Mon, 13 Aug 2012 16:46:54 -0400 (EDT) In-Reply-To: <87d32u7smb.fsf@fleche.redhat.com> (Tom Tromey's message of "Mon, 13 Aug 2012 08:51:08 -0600") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV4309=0 X-NAI-Spam-Version: 2.2.0.9309 : core <4309> : streams <798785> : uri <1191503> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:152495 Archived-At: > Yet one more observation here. The Bordeaux approach lets you specify > which bindings to capture. AFAIK, you can easily do that manually with the "no capture" behavior as well. > It seems to me that some such mechanism is necessary, at the very > least. Otherwise, passing a local variable into a thread seems > difficult, unless you assume that only lexical-binding:t code will > want to make threads. Converting to lexical-binding is fairly easy in my experience (at least for code whose byte-compilation doesn't spit out hundreds of warnings). So, yes, I assume that lexical-binding will be a common case for threaded code and I'm happy to make things a bit harder for the dynamic-binding case if it can make the whole approach simpler and cleaner. The concurrency code makes dynamic binding more expensive anyway (either because of the need to unwind&rewind them during context switch, or because accessing those vars requires fetching the current thread-local value), so it naturally likes lexical-binding. > Maybe everything important really will use lexical binding. At least the `make-thread' code will likely be in a lexical-binding file, yes. Stefan