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: advice needed for multi-threading patch Date: Sun, 27 Sep 2009 19:05:07 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1254092728 21909 80.91.229.12 (27 Sep 2009 23:05:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Sep 2009 23:05:28 +0000 (UTC) Cc: Emacs development discussions To: Tom Tromey Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 28 01:05:21 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 1Ms2nw-0000Jv-B5 for ged-emacs-devel@m.gmane.org; Mon, 28 Sep 2009 01:05:20 +0200 Original-Received: from localhost ([127.0.0.1]:55412 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ms2nv-0003WT-Uy for ged-emacs-devel@m.gmane.org; Sun, 27 Sep 2009 19:05:19 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ms2nq-0003WE-0E for emacs-devel@gnu.org; Sun, 27 Sep 2009 19:05:14 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ms2nl-0003W2-Gl for emacs-devel@gnu.org; Sun, 27 Sep 2009 19:05:13 -0400 Original-Received: from [199.232.76.173] (port=49345 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ms2nl-0003Vz-Av for emacs-devel@gnu.org; Sun, 27 Sep 2009 19:05:09 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:36514 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ms2nk-0007mR-RZ for emacs-devel@gnu.org; Sun, 27 Sep 2009 19:05:08 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIEAA+Mv0pFxIo//2dsb2JhbACBUNBThB4Fh30 X-IronPort-AV: E=Sophos;i="4.44,462,1249272000"; d="scan'208";a="46679229" Original-Received: from 69-196-138-63.dsl.teksavvy.com (HELO pastel.home) ([69.196.138.63]) by ironport2-out.pppoe.ca with ESMTP; 27 Sep 2009 19:05:08 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id E9EC980C4; Sun, 27 Sep 2009 19:05:07 -0400 (EDT) In-Reply-To: (Tom Tromey's message of "Sun, 27 Sep 2009 14:59:02 -0600") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) 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:115702 Archived-At: Stefan> Indeed. The lock should probably be on the buffer-local binding itself Stefan> (i.e. the combination of the buffer and the variable). > I looked into this a bit; I think it can lead to deadlock too easily: > Thread A acquires V1 and requests V2 > Thread B acquires V2 and requests V1 > Instead, I think we could remove the buffer lock. Because we currently > use cooperative threading, most buffer operations are atomic with > respect to thread switches. So, it seems that if we fix the bindings > problem, we can probably just remove the buffer lock. Removing locks sounds like a wonderful solution, but it's dangerous. I think you understand the danger and refer to it as "the bindings problem". But since I'm not sure I'll state what I think is the problem: thread T1 goes into buffer B and does a dynamic let-binding of buffer-local variable X with value V1, then thread T2 does the same thing with value V2. What should that mean? What should T1 see when it looks at X, V1 or V2? What should T2 see when it looks at X, V1 or V2? What did T2 see when it looked at X before let-binding it, V1 or V0? What should T1 see when it looks at X after T2 ends its let-binding, V1 or V0? What should T2 see when it looks at X after T1 ends its let-binding, V2 or V0? You have to consider those cases and then look at existing code and see what that code would expect. A good variable to start with is probably default-directory (one of the most common buffer-local-and-let-bound variables I know of), but others need to be considered as well (I'm not sure they'll all agree on the behavior they expect). Stefan PS: Of course, similar questions arise with let-binding frame-local and terminal-local variables, but I think these are much less common, so it's probably OK to be less careful with them and just fix up the places that break using explicit locks or things like that.