[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
advice needed for multi-threading patch
From: |
Tom Tromey |
Subject: |
advice needed for multi-threading patch |
Date: |
Tue, 25 Aug 2009 22:38:41 -0600 |
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
- advice needed for multi-threading patch,
Tom Tromey <=
Re: advice needed for multi-threading patch, Tom Tromey, 2009/08/26