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

[David Kastrup <dak@gnu.org>]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On 07 Dec 2003, monnier@iro.umontreal.ca wrote:
> 
> > Now, that doesn't mean you can't do it, but just that it's going
> > to be a lot of work and it might introduce subtle
> > incompatibilities, so you need a lot of motivation to start the
> > effort and you'll need really good arguments to convince RMS that
> > breaking compatibility is worth the pay off.  Now what is the
> > payoff ?  Speed.  Given the fact that elisp is known to be slow,
> > and that pretty much no work has been done to speed up Emacs in
> > the last N years, I get the impression that nobody really cares
> > about speed here.
> 
> I have faith that the applications will come, once the core supports
> them.  Just think, for instance, of a mapcar that spreads out onto
> as many processors as possible - doesn't that sound exciting?

No.  We are talking about an editor here, not a number crunching
package.  One fundamental difference is that a vast majority of Emacs
Lisp constructs is _supposed_ to have side effects, in spite of being
written in a functional language.

> In addition, I should point out that speed in itself is not my
> stated goal.  Yes, maybe there will be some speed improvements, but
> that's not what I've been asking for.  Multithreading makes software
> more responsive to the user, especially if the UI thread can be
> separated from the other threads.  Even if the software is actually
> slower, it will serve the user better when it's more responsive, and
> it will seem faster.  I'm generalizing quite a bit, but have you
> ever waited for a web browser to load all the images before
> proceeding to use the web page?  That's what using Emacs feels like
> sometimes, as wonderful as it is.

Emacs is not a browser, it is an editor.  If I execute some keystrokes
that will mark a region and then press the delete key before the
operation that will mark the region actually has completed, I won't be
happy if it instead deletes what happens to be at the time marked by
something else.  I don't want Emacs to start executing keystrokes
before it has processed the previous keystrokes.  I _want_ Emacs in
general to process the things in the correct order when editing.

> That being said, I realize that asking the Emacs developers to drop
> other work to write multi-threading support is a tough call, and I'm
> not the one to make it.  I just hope the core developers get excited
> enough about the possibilities that they will plan for some sort of
> multithreading.

See above comment from Stefan.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum