Re: multi-threaded Emacs

[Chetan Pandya]

--- 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