Re: Are there plans for a multi-threaded Emacs?

[David Kastrup <dak@gnu.org>]

Martin Stjernholm <mast@lysator.liu.se> writes:

> Ted Zlatanov <tzz@lifelogs.com> wrote:
> 
> >> o  To be able to run several threads simultaneously in multicpu or
> >>    hyperthreaded systems.
> >> o  To get OS level preemption between threads.
> >
> > Those two benefits make a big difference.
> 
> The last does not since it's quite feasible to simulate, as I've
> outlined. (I know that from practical experience with this threading
> model in a language environment fairly similar to elisp.)
> 
> > Today's Pentiums have hyper-threading technology, so even a single
> > processor can act as two.
> 
> True. Hyperthreading is becoming more commonplace.
> 
> > The best cooperative multitasking can't make use of multiple
> > processors as well as premptive multithreading.
> 
> I don't see how preemption per se can improve parallell execution.

It's not preemption, but preemption aware coding, and it does not
improve parallel execution but is a prerequisite for it.

> Fine grained locking can, but it's hard to avoid making it too fine
> grained so that the locking itself becomes more time consuming than
> the speedup from the improved parallellism it achieves.

For that reason it is important to have as few locks necessary as
possible.  And having to lock on the binding table would be
prohibitively expensive.

> Anyway, a way to cope with such heavy tasks could be to make it easy
> to fork a separate interpreter with its own data set. It would then
> only take the main interpreter lock explicitly and rarely to
> communicate its results and request new data, or perhaps even be
> restricted to communication through a pipe.

`fork' is a system call that is not available for a considerable
number of Emacs runtime platforms.  Relying on it might not be the
best choice for such a feature, apart from the obvious problems with
having two copies of Emacs with open buffers of their own around.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum