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: advice needed for multi-threading patch Date: Tue, 25 Aug 2009 22:38:41 -0600 Message-ID: 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 1251261544 9556 80.91.229.12 (26 Aug 2009 04:39:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 26 Aug 2009 04:39:04 +0000 (UTC) To: Emacs development discussions Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 26 06:38:57 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 1MgAHg-00012M-GL for ged-emacs-devel@m.gmane.org; Wed, 26 Aug 2009 06:38:56 +0200 Original-Received: from localhost ([127.0.0.1]:37769 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MgAHg-0003Vm-00 for ged-emacs-devel@m.gmane.org; Wed, 26 Aug 2009 00:38:56 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MgAHa-0003U7-F7 for emacs-devel@gnu.org; Wed, 26 Aug 2009 00:38:50 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MgAHV-0003Ob-E9 for emacs-devel@gnu.org; Wed, 26 Aug 2009 00:38:49 -0400 Original-Received: from [199.232.76.173] (port=57857 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MgAHV-0003OL-8N for emacs-devel@gnu.org; Wed, 26 Aug 2009 00:38:45 -0400 Original-Received: from mx1.redhat.com ([209.132.183.28]:9406) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MgAHU-0008Ps-Na for emacs-devel@gnu.org; Wed, 26 Aug 2009 00:38:45 -0400 Original-Received: from int-mx06.intmail.prod.int.phx2.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.19]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n7Q4chT6030946 for ; Wed, 26 Aug 2009 00:38:43 -0400 Original-Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx06.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n7Q4cg1Y023710; Wed, 26 Aug 2009 00:38:43 -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 n7Q4cf6F015406; Wed, 26 Aug 2009 00:38:42 -0400 Original-Received: by opsy.redhat.com (Postfix, from userid 500) id 884C43782A4; Tue, 25 Aug 2009 22:38:41 -0600 (MDT) X-Attribution: Tom X-Scanned-By: MIMEDefang 2.67 on 10.5.11.19 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:114603 Archived-At: I was inspired by Giuseppe Scrivano's work from last year: http://lists.gnu.org/archive/html/emacs-devel/2008-11/msg01067.html ... so I started working on my own patch to implement multi-threading in Emacs. I've tried to follow Stefan's advice as given in that thread. In particular I've (initially) implemented cooperative multi-threading. Some background for my particular question: My implementation of dynamic binding uses a structure like so: struct Lisp_ThreadLocal { enum Lisp_Misc_Type type : 16; /* = Lisp_Misc_ThreadLocal */ unsigned gcmarkbit : 1; int spacer : 15; Lisp_Object global; Lisp_Object thread_alist; }; ... the idea being that a let-bound variable will be on 'thread_alist' (keyed by the thread), and other threads will see the value in 'global'. These objects are found in symbol value slots. I managed to handle the V* global variables by writing some elisp that changed every declaration of a variable mentioned in a DEFVAR_LISP from Vfoo to impl_Vfoo and also emitted a new header with a lot of: #define Vfoo *find_variable_location (&impl_Vfoo) This was pretty simple and non-intrusive, in the sense that it is totally automated, so I can easily reapply it as Emacs changes. ... 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'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... Tom