[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: multi-threaded Emacs
From: |
Chetan Pandya |
Subject: |
Re: multi-threaded Emacs |
Date: |
Sun, 30 Nov 2008 16:10:53 -0800 (PST) |
--- On Sun, 11/30/08, Giuseppe Scrivano <address@hidden> wrote:
> From: Giuseppe Scrivano <address@hidden>
> Subject: Re: multi-threaded Emacs
> To: "Miles Bader" <address@hidden>
> Cc: address@hidden, address@hidden
> Date: Sunday, November 30, 2008, 11:09 PM
> Miles Bader <address@hidden> writes:
>
> > BTW, there was a huge thread maybe a year (?) or so
> ago about this subject.
> > Have you read it?
> >
> > IIRC, the basic consensus was that some sort of
> explicitly
> > non-preemptive threading was probably the best
> solution for emacs.
> >
> > -Miles
>
> I found a thread of 3 years ago (maybe is it this one?
> Time passes very
> fast :) ) but I didn't find any conclusion.
>
> Anyway, a non-preemptive threading will not give any real
> parallelism
> and it will require more changes in the Elisp packages to
> use threads as
> they will need to say explicitly when give the control to
> another
> thread.
> Instead `run-in-thread' will setup the call stack and
> finally give the
> control to the thread. The only change required in the
> Elisp packages
> to be used in a multithreaded environment is to protect
> global data
> accesses with a lock/unlock, but how many times does it
> happen to change
> the value of a global variable?
>
> Both solutions require changes in Elisp, a non-preemptive
> threading
> needs to explicitly yield the control to another thread,
> while having
> real threads needs to specify when access to global data
> must be
> protected. The latter one differently allows parallelism
> and I guess
> less changes in the Elisp code too (if writes to global
> data are less
> frequent than specify when exit from the current thread).
>
> Giuseppe
A non-preemptive threading model can also yield implicitly, but can have
unexpected consequences - for example a global variable changing value between
two uses within a function, or if two values that are modified together. In
general, such transaction semantics have to be coded explicitly in a preemptive
threading model, where as with a cooperative model, one has to be aware of only
a few of such points.
Perhaps these things were discussed earlier. I will take a look.
Chetan
- Re: multi-threaded Emacs, (continued)
Re: multi-threaded Emacs, Tom Tromey, 2008/11/29
Re: multi-threaded Emacs, Richard M Stallman, 2008/11/30
- Re: multi-threaded Emacs, Giuseppe Scrivano, 2008/11/30
- Re: multi-threaded Emacs, Miles Bader, 2008/11/30
- Re: multi-threaded Emacs, Stefan Monnier, 2008/11/30
- Re: multi-threaded Emacs, Giuseppe Scrivano, 2008/11/30
- Re: multi-threaded Emacs,
Chetan Pandya <=
- Re: multi-threaded Emacs, Stefan Monnier, 2008/11/30
Re: multi-threaded Emacs, Miles Bader, 2008/11/30
Re: multi-threaded Emacs, Richard M Stallman, 2008/11/30