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

[Ted Zlatanov]

On 04 Dec 2003, address@hidden wrote:

> David Kastrup <address@hidden> writes:
> 
>> Ted Zlatanov <address@hidden> writes:

>> > Converting a single-threaded application to multithreaded,
>> > especially one as complex as Emacs, is a daunting task.  I think
>> > it's worthwhile.
>> 
>> Not everything that is worthwhile gets done.  
> 
> I don't really agree that this is worthwhile.
> 
> IMO, there are many other improvements that are more important than
> multi-threading.  Of course, if we had unlimited development _and_
> _testing_ resources, it would be a nice thing to add, but I don't
> like the idea of adding something _really complex_ like that which
> may potentially de-stabilize emacs for a long time.

I meant it's worthwhile to add multithreading to Emacs, not that it
should override other, more important tasks for the Emacs developers.
I'm sorry if I gave the wrong impression.

> Even if you add multi-threading to Elisp, the applications need to
> be made aware of that.  How much -additional- work would be it be to
> rework, say, GNUS to be multi-threaded?

Specifically with Gnus the work would be pretty extensive.  Gnus
relies on a lot of buffer-local and global variables.  I'd personally
commit quite a few hours to that project because it will be fun.

> Actually, a lot of code could already be improved today with better
> use of process filters and sentinels, but that hasn't been done.  So
> even if we had multi-threading, I doubt that it would be widely
> used.

I don't think process filters would help much if I wanted to look up
several entries in a hashtable in parallel to build an article
summary buffer.  Right now, doing this sequentially is the only way,
and consequently doing fancy things while building the summary buffer
is not a good idea.

What I mean is, say we have N articles in a mail-group (in Gnus, seen
in the summary buffer).  For each article, I want to look up certain
things in a hashtable.  I am sure that the lookups will not involve
any variable modifications.  I'd rather start N or (fraction of N)
threads than do N sequential lookups.

This is just an example for Gnus, because I'm most familiar with that
application.  I'm sure that other applications, for instance anything
that does parallel independent calculations, will benefit from
multithreading as opposed to process filters or sentinels.

> I still wonder why people want multi-threading in Elisp -- IMHO,
> emacs works just fine without it!

For example, gnuclient could be used to get immediate results instead
of waiting for the current task to complete.  That would be useful.

> I admit (synchronous) GNUS is a problem, but except for that, I
> don't really see that much code which will benefit vastly from being
> executed by a multi-threaded emacs.

I don't think vast improvements can be expected, either.  It will
improve the user experience, though.

> And for GNUS, you can just run two instances of emacs on your
> multi-tasking OS.
> 
> Likewise, if you have some vast app writting in Elisp, just start
> a second emacs to run it.
> 
> Problem solved!

Come on, that's giving up on the problem.  I already run two copies of
Emacs, one for editing and one for Gnus.  There's problems with that.
For instance, files I open in the one that quits first don't get in
the .session file because the second one overwrites the .session
file.

Ted