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

[Ted Zlatanov <tzz@lifelogs.com>]

On 07 Dec 2003, monnier@iro.umontreal.ca wrote:

> Making Emacs scalable is probably best done by starting all over
> from scratch.  The current structure of the C code together with the
> semantics of elisp means that it's about as far from scalable as
> you'll ever get.
> 
> 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?

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.

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.

> What people do care about a little is the "non-blocking thingy"
> which might require some form of multithreading but does not require
> any kind of scalability and does not require nearly as much work
> (and as much breakage of backward compatibility).  So I'd recommend
> people start with this if they want to work on something like that.
> Once this is done, we might be able to start thinking about
> scalability.

I'm convinced, based on the many posts made, that the best way to
approach multithreading is slowly and incrementally.  I would not
dream of imposing any particular implementation, but it does seem that
most people prefer a single "main" thread and no preemption, since
those would preserve backwards compatibility best.

Ted