Re: multi-threaded Emacs

[Helmut Eller]

* Miles Bader [2008-12-05 09:20+0100] writes:

> This is because emacs, being an interactive system, generally doesn't
> have a lot of long-running code.  It's the relatively few exceptions to
> this rule (e.g. gnus reading in new messages) that are the main issues
> in practice.  Fixing those places will probably yield a lot of benefit
> for (relatively) small amount of work.

I'm wondering what the exact problem with Gnus is.

Certainly, downloading the next article takes a bit of time but threads
wont make the download any faster.  Is there something the user wants to
do while waiting for the next article?

There's also something called "gnus-async" which supposedly downloads
articles in the background.  It's clearly possible to do I/O in the
background with ordinary process-filters; we need no threads for that.
It's probably a bit harder to parse messages in process-filters as with
threads, but threads are also tricky (preemptive or not).

Opening a connection can also take some time, but again, it can be done
asynchronously with the :nowait argument to make-network-process.  I
don't know if Gnus uses this possibility.  It would be interesting to
know what is easier: adding threads or rewriting Gnus with
process-filters.

Threads could probably be used to "stop" the current command and
continue it in the background.  Something like job control in a shell.
That would be a nice feature, but I don't know if it is worth all the
complexity that threads introduce.

Helmut.