Re: Gnus' speed

[Daniel Pittman <daniel@rimspace.net>]

Tom Tromey <tromey@redhat.com> writes:
>>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:
>
> Ted> But there's a bigger problem: Gnus is by design synchronous.  You
> Ted> enter a group, then wait for the summary buffer to be built.  Gnus
> Ted> doesn't have the concept of "enter a buffer and let the articles
> Ted> come in asynchronously" and I doubt it's possible without some
> Ted> multithreading support in Emacs Lisp, which has been discussed many
> Ted> times but is probably far in the future (at least a year, judging
> Ted> by threads in emacs-devel).  Gnus blocks on many other operations
> Ted> too.
>
> Do you mean, this can't be done without threads because it means too
> much rewriting of Gnus?

No, because it requires rewriting of *Emacs* to add support for threads.

That, in turn, would require rebuilding the Emacs Lisp engine to support
concurrency, which in turn will drive you completely insane because a
completely dynamically scoped language doesn't play nicely with threads.

However, if you are seriously interested there is currently some little effort
in either implementing ELisp in Guile, or adding threads, discussed in the
Emacs development groups over the last few months.

> It seems to me that in theory Gnus could work asynchronously by doing work
> in process filters.

Actually, you could also do it with idle timers, and/or redisplay stuff, but
this is enormously non-trivial to achieve and requires rewriting most of the
core of Gnus.

Regards,
        Daniel
-- 
✣ Daniel Pittman            ✉ daniel@rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons