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: Wed, 26 Aug 2009 11:02:58 -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 1251299186 21805 80.91.229.12 (26 Aug 2009 15:06:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Aug 2009 15:06:26 +0000 (UTC) Cc: Emacs development discussions To: Tom Tromey Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 26 17:06:19 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 1MgK4p-0004yq-2b for ged-emacs-devel@m.gmane.org; Wed, 26 Aug 2009 17:06:19 +0200 Original-Received: from localhost ([127.0.0.1]:55037 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MgK4o-00014P-FI for ged-emacs-devel@m.gmane.org; Wed, 26 Aug 2009 11:06:18 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MgK1g-0008LB-P1 for emacs-devel@gnu.org; Wed, 26 Aug 2009 11:03:04 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MgK1c-0008JE-05 for emacs-devel@gnu.org; Wed, 26 Aug 2009 11:03:04 -0400 Original-Received: from [199.232.76.173] (port=39782 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MgK1b-0008J8-Q9 for emacs-devel@gnu.org; Wed, 26 Aug 2009 11:02:59 -0400 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]:46253 helo=ironport2-out.teksavvy.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MgK1b-0000CG-Bb for emacs-devel@gnu.org; Wed, 26 Aug 2009 11:02:59 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAEfrlEpFpYuS/2dsb2JhbACBU9c+hBoFh2I X-IronPort-AV: E=Sophos;i="4.44,279,1249272000"; d="scan'208";a="44230164" Original-Received: from 69-165-139-146.dsl.teksavvy.com (HELO pastel.home) ([69.165.139.146]) by ironport2-out.teksavvy.com with ESMTP; 26 Aug 2009 11:02:05 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 6E6797F42; Wed, 26 Aug 2009 11:02:58 -0400 (EDT) In-Reply-To: (Tom Tromey's message of "Tue, 25 Aug 2009 22:38:41 -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:114617 Archived-At: > ... which brings me to my problem. I'd also like to apply a similar > treatment to buffer-local variables. However, those do not have > convenient accessor macros, and before starting the laborious task of > wrapping all buffer field accesses, I thought I'd ask for advice. Is > this a sane way to proceed? Should I do something different? Could I > get such a patch in before the rest of this work, just to make my local > divergence smaller? I'm not sure I understand what you want to do and which problem you want to solve. In my mind, in the first iteration of "adding multithreading to Emacs", no buffer could have two active threads at the same time (i.e. set-buffer would impose some kind of synchronization). In such a context, I think that buffer-local variables (and fields in the buffer structures) don't need any special treatment, right? > I'll also note that the above approach does not work for DEFVAR_INT. > I have a plan for those but I fear it is somewhat expensive. If you > have an idea... You can start with #define Vfoo XINT(*find_variable_location (&impl_Vfoo)) and then fix up all the cases where the variable in accessed as an lvalue. In general, I'm not opposed to introducing macros for such accesses in the trunk, if it can make such work easier. Stefan