[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Luke A. Olbrish
Subject: Re: Are there plans for a multi-threaded Emacs?
Date: Sun, 07 Dec 2003 20:26:38 -0500
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux)

Stefan Monnier <address@hidden> writes:

>> efficient for single processor machines.  Read the paper: "Flash: an
>> Efficient and Portable Web Server".  The creators implement an event
>> driven model for web serving and get significantly better performance
>> than staple web servers like apache.  Even lightweight threads have
> Note that there's a reason why Apache does not use an event-driven approach:
> it's a lot more painful to write.  So comparing performance of X with Apache
> is kind of like comparing the performance of sed with the performance of
> Emacs.  Except that some people do try to make Apache faster (even though
> it's not the main focus of development, far from it), whereas noone does
> that for Emacs.

My comments stem more from Ted's use of various thread implementation
keywords than the concept of threads.

It is very true that threading models tend to be more flexible than
event driven models.  Though I wonder if some more thought was put
into building an event driven paradigm for a language, if programmers
could often get what they want without resorting to threads.  Many
programmers do not know how to properly create threaded programs.
Ideally, a nice event driven mechanism and a nice threading mechanism
would exist and programmers would be free to choose the best paradigm
for their program.

> So I think if we want some kind of parallelism, the most important aspect
> for Emacs would be convenience of elisp coding rather than efficiency.

Well if we are going to get into a discussion of the convenience of
elisp, maybe its time to discuss dynamic scoping.  This would be a
personal peeve though and many mind find the willy-nilly identifier
capabilities of dynamic scoping to be convenient.

Luke Anthony Olbrish

reply via email to

[Prev in Thread] Current Thread [Next in Thread]