Re: What's the problem? (Was: Are there plans for a multi-threaded Emacs?)

[Ted Zlatanov <tzz@lifelogs.com>]

On 08 Dec 2003, luke@bluetail.com wrote:

> What's the biggest problem that threads are intended to solve?

(I'm talking about my own comments in this thread, and I'll try to
summarize things)

The interactive user experience, when tasks can be parallelized or
backgrounded, could be *improved.*  This is not a problem to be
solved, it's an incremental improvement from the user's viewpoint.

> Is it that it's too hard or ugly to write concurrent programs in
> Elisp today? If so, what are some examples of bad cases that cause
> users pain and _really_ can't be rewritten neatly and with happy
> concurrency properties in plain old Elisp after some rethinking?

Note I don't claim these can't be rewritten in a concurrent fashion.
I simply gave examples that could stand to be improved.  The majority
of examples are in Gnus, because that's the Elisp application I know
best.

- auto-save on a slow file system or through Tramp

- Gnus mail retrieval, summary thread building, registry lookups

- independent hashtable lookups and calculations in parallel would be
  a very nice improvement in themselves, and I'm sure there are many
  applications that can use them

> People are writing concurrent programs in Elisp today. Most programs
> interacting with external processes and sockets do so without
> blocking Emacs. Can't we all just do the same?

There seems to be interest in a real multithreading solution, be it
cooperative or preemptive, or an event-driven API.  I'm OK with any
solution as long as it improves the user experience, and I'll work
with whatever API is best.  I would like that API to exist, though,
and that doesn't seem to be the case with concurrency in Emacs
today.  Am I wrong?

If it appears from this thread that I have a particular interest in a
radical rewrite of Emacs, that is not true.  It just seems to me,
because of the tight internal coupling of Emacs functions and
variables, that lightweight threads would be a good choice for the
internal implementation of the API because they have less baggage
than process sentinels and share data more easily.  I also mentioned
that today's hardware and OS support for it generally means that
either multiple processors or the illusion of them is available to
applications that are willing to make use of those capabilities.

Ted