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: advice needed for multi-threading patch Date: Sun, 27 Sep 2009 22:27:01 -0600 Message-ID: References: Reply-To: Tom Tromey NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1254112045 24193 80.91.229.12 (28 Sep 2009 04:27:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Sep 2009 04:27:25 +0000 (UTC) Cc: Emacs development discussions To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 28 06:27:18 2009 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.50) id 1Ms7pU-0002xt-P7 for ged-emacs-devel@m.gmane.org; Mon, 28 Sep 2009 06:27:17 +0200 Original-Received: from localhost ([127.0.0.1]:46872 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ms7pU-0002JW-13 for ged-emacs-devel@m.gmane.org; Mon, 28 Sep 2009 00:27:16 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ms7pP-0002JH-KN for emacs-devel@gnu.org; Mon, 28 Sep 2009 00:27:11 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ms7pJ-0002Ix-VL for emacs-devel@gnu.org; Mon, 28 Sep 2009 00:27:10 -0400 Original-Received: from [199.232.76.173] (port=35818 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ms7pJ-0002Iu-Rq for emacs-devel@gnu.org; Mon, 28 Sep 2009 00:27:05 -0400 Original-Received: from mx1.redhat.com ([209.132.183.28]:41844) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ms7pJ-0000VA-C8 for emacs-devel@gnu.org; Mon, 28 Sep 2009 00:27:05 -0400 Original-Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n8S4R42w024573; Mon, 28 Sep 2009 00:27:04 -0400 Original-Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n8S4R3L9031800; Mon, 28 Sep 2009 00:27:04 -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 n8S4R2T5004590; Mon, 28 Sep 2009 00:27:02 -0400 Original-Received: by opsy.redhat.com (Postfix, from userid 500) id DD99D37818C; Sun, 27 Sep 2009 22:27:01 -0600 (MDT) X-Attribution: Tom In-Reply-To: (Stefan Monnier's message of "Sun, 27 Sep 2009 19:05:07 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) X-Scanned-By: MIMEDefang 2.67 on 10.5.11.21 X-detected-operating-system: by monty-python.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:115709 Archived-At: Stefan> Removing locks sounds like a wonderful solution, but it's dangerous. Stefan> I think you understand the danger and refer to it as "the bindings Stefan> problem". But since I'm not sure I'll state what I think is the Stefan> problem: Yes. I forgot to write something important in that message, which is what I think should happen. Stefan> thread T1 goes into buffer B and does a dynamic let-binding of Stefan> buffer-local variable X with value V1, then thread T2 does the same Stefan> thing with value V2. Stefan> What should that mean? In my view, a let-binding should always be thread-local, and I think buffer-localness shouldn't affect this. This is enough of a rule to answer your questions -- but it is just one choice, we could make others, I suppose. The primary reason I like this particular choice is that it seems least susceptible to races when running ordinary lisp code in parallel. Also, it is simple to understand and consistent with the behavior of non-buffer-local let-bindings. Stefan> You have to consider those cases and then look at existing code and see Stefan> what that code would expect. A good variable to start with is probably Stefan> default-directory (one of the most common buffer-local-and-let-bound Stefan> variables I know of), but others need to be considered as well (I'm not Stefan> sure they'll all agree on the behavior they expect). I don't think existing code could have an expectation, simply because existing code can't run multi-threaded. The closest thing are process filters, but I am not so sure that they are a good analogy in this case. There are some oddities implied by making buffer-local let-bindings also be thread-specific. For example, some buffer-locals affect redisplay, so what the user sees will depend on the thread in which redisplay is run. Tom