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

[Ted Zlatanov]

On Thu, 04 Dec 2003, address@hidden wrote:

Ted Zlatanov <address@hidden> wrote:

>> The best cooperative multitasking can't make use of multiple
>> processors as well as preemptive multithreading.
> 
> I don't see how preemption per se can improve parallell execution.
> 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.

Not all threads need to be aware of each other.  Not all threads will
compete for the same resources.  Not all threads, in a cooperative
setup, will cooperate with each other due to programmer or design
error.  Also, I actually think it's easier to program for preemptive
multithreading because you write thread-safe code instead of
reengineering your code to fit the cooperative model.

>> /.../ Converting a single-threaded application to multithreaded,
>> especially one as complex as Emacs, is a daunting task.  I think
>> it's worthwhile.
> 
> I gather then that one important goal for you with the thread
> support is to make Emacs utilize true parallell execution better,
> i.e. it's for performance reasons and not only to let elisp
> developers take advantage of the threading paradigm.

Yes.

> I don't regard that performance gain as significant, at least not
> compared to the amount of work involved. Emacs is still an
> interactive application, and as such it essentially only responds to
> user actions.  Granted, there are some elisp packages that
> occasionally can be very heavily cpu bound, but they are afterall
> only a few exceptions. The only case when true parallell execution
> would improve things are when two or more such tasks are run
> concurrently. I regard that as an extremely rare situation, but you
> would probably disagree?

It's rare currently because it's not possible.  I think the
application will come once the support for them is built.

Here's more examples: font-locking a buffer; reading or writing a
file.  Cooperative or preemptive multithreading would make them a more
pleasant user experience.

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

Heavyweight threads are a problem because, as I mentioned already,
Emacs is such a tightly coupled environment.  I think lightweight
threads are better for performance.

Ted