From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tom Tromey Newsgroups: gmane.emacs.devel Subject: Re: Concurrency Date: Sun, 28 Mar 2010 15:17:49 -0600 Message-ID: References: <27349166.post@talk.nabble.com> <27560255.post@talk.nabble.com> <4B754E74.8060705@swipnet.se> <27563610.post@talk.nabble.com> <4B7564C7.1010309@swipnet.se> <27564728.post@talk.nabble.com> <4B756FB7.3050202@swipnet.se> <87k4ui4gik.fsf@lola.goethe.zz> <27566385.post@talk.nabble.com> <87wryi2sjd.fsf@lola.goethe.zz> <27585994.post@talk.nabble.com> <87k4ucdmwh.fsf@stupidchicken.com> <87d3zweq4e.fsf@master.homenet> <87y6hg1h4a.fsf@thor.thematica.it> <87tys3j9fa.fsf@lifelogs.com> <87eij6tqmu.fsf@lifelogs.com> Reply-To: Tom Tromey NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1269811089 14020 80.91.229.12 (28 Mar 2010 21:18:09 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 28 Mar 2010 21:18:09 +0000 (UTC) Cc: Ted Zlatanov , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 28 23:18:05 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Nvzrw-0000Au-Ej for ged-emacs-devel@m.gmane.org; Sun, 28 Mar 2010 23:18:04 +0200 Original-Received: from localhost ([127.0.0.1]:42848 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nvzrv-0005Kz-Kn for ged-emacs-devel@m.gmane.org; Sun, 28 Mar 2010 17:18:03 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nvzro-0005G0-9n for emacs-devel@gnu.org; Sun, 28 Mar 2010 17:17:56 -0400 Original-Received: from [140.186.70.92] (port=39101 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nvzrm-0005D3-WB for emacs-devel@gnu.org; Sun, 28 Mar 2010 17:17:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nvzrl-0002XW-MQ for emacs-devel@gnu.org; Sun, 28 Mar 2010 17:17:54 -0400 Original-Received: from mx1.redhat.com ([209.132.183.28]:55524) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nvzrl-0002XO-Ee for emacs-devel@gnu.org; Sun, 28 Mar 2010 17:17:53 -0400 Original-Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o2SLHpmC011494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 28 Mar 2010 17:17:51 -0400 Original-Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o2SLHoCW021056; Sun, 28 Mar 2010 17:17:50 -0400 Original-Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id o2SLHnqU015595; Sun, 28 Mar 2010 17:17:50 -0400 Original-Received: by opsy.redhat.com (Postfix, from userid 500) id 4F99A88852D; Sun, 28 Mar 2010 15:17:49 -0600 (MDT) X-Attribution: Tom In-Reply-To: (Stefan Monnier's message of "Sun, 28 Mar 2010 16:03:37 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:122826 Archived-At: Stefan> Could someone complete the above with a description of how Stefan> let-bindings work (and/or how they interact with buffer-local Stefan> bindings)? A let binding is always thread-local. This is true whether the variable is buffer-local or not. The view within a single thread is basically the same as how elisp works today. The interaction of let-bindings and buffer-local bindings is complicated, but I think really no different from before. At least, that was our goal, of course there could be bugs. Stefan> Also, a list of bugs/problem/issues would be handy, * Documentation; NEWS, as you said, but also the lisp reference manual. * The current code makes no attempt to portable, it relies on POSIX threads and the GNU __thread extension. This is not too hard to fix. I think it is reasonably important to keep __thread on systems that support it, for performance. * Suppose you have existing elisp that creates a process with a filter, and the filter changes a let-bound variable, and the "outer" elisp blocks in sit-for waiting for the filter to do its thing. Nothing in the current code guarantees that the process filter will be run in the "correct" thread. * There may be oddities with redisplay running in the "wrong" thread. * Keyboard-local variables and let-bindings may not work together as expected. I'm sure there are more, this is all I remember offhand. Stefan> PS: And place this info in a file in the `concurrent' branch. I hope someone else can do that. Tom