Re: What's the problem?

[Simon Josefsson]

Miles Bader <address@hidden> writes:

> Simon Josefsson <address@hidden> writes:
>> > It depends on your environment of course -- if you have a slow network
>> > connection (or a slow server), it can spend a _lot_ of time waiting for
>> > external processes/data.
>> 
>> Right, with emphasis on _can_.
>
> At least for me, this is an issue every single day; the CPU-bound parts
> of summary generation &c are slightly annoying, but really not enough to
> warrant any massive rewriting -- on the order of 30s or so for a large
> newsgroup -- but IO-bound delays can be 10 _minutes_.  I don't know what
> it's like for other people.

I'm using the Agent in recent Gnus, so almost all data is locally
cached (except for flag updates via IMAP and new-mail checks in NNTP),
so for me the delays I see are mostly CPU bound.

>> > Anyway my main point is that I think it's basically an application
>> > issue, though emacs might help by adding helper functions.
>> 
>> I don't see how fixing my perceived problem can be done without some
>> kind of threading support in Emacs (co-operative or whatever).  Hence,
>> helper functions would do more than just help, they are critical in
>> improving the application.
>
> What I'm trying to say is that the `threading support' need not be
> particularly good, or general-purpose.  Probably something could be
> hacked up right _now_, without any additional core functions, using
> clever programming and emacs timers, by changing the worst-offending
> part of the gnus code into something event driven.

I don't understand.  How would making the summary buffer generation
asynchronous stop Emacs from locking up during computations?  For me,
the summary buffer generation is CPU bound in elisp, not IO bound.
Same for getting new mail into the agent, it can take 2-3 minutes with
only a fraction of the time spent in IO (yes, it is not optimized).

I agree doing what you suggest would improve your problem, and making
Gnus more asynchronous would be useful (patches welcome!), but I don't
see how it is relevant to stopping the lockups when processing data.

I think there are two separate problems here.  They can and need to be
solved individually.