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: Wed, 26 Aug 2009 09:31:34 -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 1251300762 27694 80.91.229.12 (26 Aug 2009 15:32:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Aug 2009 15:32:42 +0000 (UTC) Cc: Emacs development discussions To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 26 17:32:35 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 1MgKUE-0006b0-SV for ged-emacs-devel@m.gmane.org; Wed, 26 Aug 2009 17:32:35 +0200 Original-Received: from localhost ([127.0.0.1]:40787 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MgKUE-0001Fe-1t for ged-emacs-devel@m.gmane.org; Wed, 26 Aug 2009 11:32:34 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MgKTQ-0000vs-AN for emacs-devel@gnu.org; Wed, 26 Aug 2009 11:31:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MgKTL-0000rC-B1 for emacs-devel@gnu.org; Wed, 26 Aug 2009 11:31:43 -0400 Original-Received: from [199.232.76.173] (port=50289 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MgKTL-0000r6-6V for emacs-devel@gnu.org; Wed, 26 Aug 2009 11:31:39 -0400 Original-Received: from mx1.redhat.com ([209.132.183.28]:24739) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MgKTK-0005Ew-M6 for emacs-devel@gnu.org; Wed, 26 Aug 2009 11:31:39 -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 n7QFVbOR014688; Wed, 26 Aug 2009 11:31:37 -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 n7QFVadV030201; Wed, 26 Aug 2009 11:31:37 -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 n7QFVZoA004650; Wed, 26 Aug 2009 11:31:35 -0400 Original-Received: by opsy.redhat.com (Postfix, from userid 500) id 0200B3782A9; Wed, 26 Aug 2009 09:31:34 -0600 (MDT) X-Attribution: Tom In-Reply-To: (Stefan Monnier's message of "Wed, 26 Aug 2009 11:02:58 -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:114618 Archived-At: >>>>> "Stefan" == Stefan Monnier writes: Tom> ... which brings me to my problem. I'd also like to apply a similar Tom> treatment to buffer-local variables. However, those do not have Tom> convenient accessor macros, and before starting the laborious task of Tom> wrapping all buffer field accesses, I thought I'd ask for advice. Is Tom> this a sane way to proceed? Should I do something different? Could I Tom> get such a patch in before the rest of this work, just to make my local Tom> divergence smaller? Stefan> I'm not sure I understand what you want to do and which problem you want Stefan> to solve. I'm trying to properly implement per-thread let binding in the presence of buffer-local variables. I was planning to do this by inserting a thread-based lookup anywhere a buffer-local was accessed. However, to do this, I need to insert a function call anywhere a field corresponding to a DEFVAR_PER_BUFFER is used. So, e.g., I would like to change: b->major_mode = Qfundamental_mode; to: BUFFER_MAJOR_MODE (b) = Qfundamental_mode; Doing this transform for all 54 DEFVAR_PER_BUFFER fields is a big pain, though, so I thought I'd ask about it first. Stefan> In my mind, in the first iteration of "adding multithreading Stefan> to Emacs", no buffer could have two active threads at the same time Stefan> (i.e. set-buffer would impose some kind of synchronization). In such Stefan> a context, I think that buffer-local variables (and fields in the buffer Stefan> structures) don't need any special treatment, right? I will try that. Tom> I'll also note that the above approach does not work for DEFVAR_INT. Tom> I have a plan for those but I fear it is somewhat expensive. If you Tom> have an idea... Stefan> You can start with Stefan> #define Vfoo XINT(*find_variable_location (&impl_Vfoo)) Stefan> and then fix up all the cases where the variable in accessed as Stefan> an lvalue. In general, I'm not opposed to introducing macros Stefan> for such accesses in the trunk, if it can make such work easier. Yeah, this was my plan :-) Tom