[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: advice needed for multi-threading patch
From: |
Giuseppe Scrivano |
Subject: |
Re: advice needed for multi-threading patch |
Date: |
Sat, 29 Aug 2009 02:28:33 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) |
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 <address@hidden> 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
- Re: advice needed for multi-threading patch, (continued)
- Re: advice needed for multi-threading patch, Ken Raeburn, 2009/08/27
- Re: advice needed for multi-threading patch, Miles Bader, 2009/08/27
- Re: advice needed for multi-threading patch, Juri Linkov, 2009/08/28
- Re: advice needed for multi-threading patch, Miles Bader, 2009/08/28
- Re: advice needed for multi-threading patch, Juri Linkov, 2009/08/28
- Re: advice needed for multi-threading patch, Miles Bader, 2009/08/28
- Re: advice needed for multi-threading patch, Richard Stallman, 2009/08/29
Re: advice needed for multi-threading patch, Stefan Monnier, 2009/08/26
Re: advice needed for multi-threading patch,
Giuseppe Scrivano <=