Re: multi-threaded Emacs

[Ted Zlatanov <tzz@lifelogs.com>]

On Fri, 05 Dec 2008 12:02:19 +0100 Helmut Eller <eller.helmut@gmail.com> wrote: 

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

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

Even assuming all server interactions can be backgrounded (they can't
AFAIK because of their current design, interacting with the global data
all over the place), one place that's slow is article splitting.  You
fetch an article, then run some rules (e.g. spam filters and registry
searches) to decide where it will go.  This can be 90% parallelized, I
would guess.

Reading mail normally has never been so slow that I wished it could be
done in the background.

Saving the newsrc file is sometimes slow, so backgrounding it would be
nice.  Of course, you don't want to garble that data so it's important
to do it right.

The Gnus registry should be asynchronous for:

- tracking article move/delete/copy/spool operations
- saving the registry file
- interacting with spam.el

spam.el should be asynchronous for:

- running a spam backend on an article
- determining the spam score of an article
- telling the registry the results of spam processing

Ted