From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Giuseppe Scrivano Newsgroups: gmane.emacs.devel Subject: Re: advice needed for multi-threading patch Date: Sat, 29 Aug 2009 02:28:33 +0200 Message-ID: <87vdk7xy32.fsf@master.homenet> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1251505833 16837 80.91.229.12 (29 Aug 2009 00:30:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 29 Aug 2009 00:30:33 +0000 (UTC) Cc: Emacs development discussions To: Tom Tromey Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 29 02:30:26 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 1MhBpp-0002eR-PI for ged-emacs-devel@m.gmane.org; Sat, 29 Aug 2009 02:30:26 +0200 Original-Received: from localhost ([127.0.0.1]:54138 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MhBpp-0007xe-2s for ged-emacs-devel@m.gmane.org; Fri, 28 Aug 2009 20:30:25 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MhBpk-0007vv-6i for emacs-devel@gnu.org; Fri, 28 Aug 2009 20:30:20 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MhBpf-0007rj-Qu for emacs-devel@gnu.org; Fri, 28 Aug 2009 20:30:19 -0400 Original-Received: from [199.232.76.173] (port=37481 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MhBpf-0007rb-JV for emacs-devel@gnu.org; Fri, 28 Aug 2009 20:30:15 -0400 Original-Received: from averell.mail.tiscali.it ([213.205.33.55]:45022) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MhBpb-0002oZ-JC; Fri, 28 Aug 2009 20:30:12 -0400 Original-Received: from master.homenet (84.223.203.86) by averell.mail.tiscali.it (8.0.022) id 49CBA13704BB7EC9; Sat, 29 Aug 2009 02:29:54 +0200 Original-Received: from gscrivano by master.homenet with local (Exim 4.69) (envelope-from ) id 1MhBo1-00058H-N5; Sat, 29 Aug 2009 02:28:33 +0200 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: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:114802 Archived-At: Hello Tom, I only now saw this thread and multi-threaded Emacs is still in my wish-list :-) Do you already have some working code? I was expecting the final migration to BZR before start working again on it. Last time that I rebased my patch, approximately two months ago, it was still working and I think something can be re-used from it. In my work, I didn't consider threads local storage for two reasons the first and most important is that elisp packages (yet?) don't know about it and wouldn't use; the second reason is that it adds a lot of complexity while I don't see much benefits so I chose simplicity. Probably threads local storage can be useful when the cooperative model will be changed to something more serious, but that is another story :-) Cheers, Giuseppe Tom Tromey writes: > 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