Re: is there a possibility for gnus to download data without blocking?

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Wayne Harris <wharris1@protonmail.com> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Wayne Harris <wharris1@protonmail.com> writes:
>>
>>> Is there a possibility for gnus to download data without blocking?
>>> Wouldn't it be nice to be able to keep using EMACS while Gnus is
>>> downloading?
>>>
>>> Is it a limitation of EMACS itself?  If so, is there any plans for
>>> supporting such things in the future?  Wouldn't it be nice?
>>
>> It would be lovely! There are a few issues: Emacs is single-threaded,
>> though it has the ability to continue execution while waiting on IO from
>> an external process. So theoretically we can already "download data
>> without blocking". In fact, Gnus already does this in a limited way:
>> when you hit "g", it starts an async external process for each of your
>> servers (each that involves an external process, anyway), then polls
>> each one until they're all done, and then continues with updating its
>> state.
>
> The fact that it uses external processes seems totally acceptable and
> perhaps even desirable.  I like external processes.  That means I could
> look at that part of the system individually using my shell.
>
>> That means there's really only a benefit when you have multiple servers
>> that can overlap their IO, and you're still going to wait as long as the
>> longest server takes.
>
> Interesting.  I haven't noticed that.  For example, when I say ``A A''
> on the group buffer to fetch a list of all groups, I see each news
> server being read one after the other.  But you didn't say this should
> have happened.  You said when I say ``g'' and I can't really tell what
> happens when I say ``g'', so I'll believe you.

Huh, I have never in my life used "A A". I just tried it, and indeed the
connections are made synchronously/consecutively. That's not a surprise,
because "g" (gnus-group-get-new-news) goes to quite a lot of trouble to
make the connections asynchronous, and that work isn't done elsewhere in
the code.

>> In theory we could have a Gnus that fires off all the servers and then
>> returns control to the user immediately, but that would involve handling
>> out-of-band returns as they came in from the servers, and Gnus would
>> have to be structured very differently than it is now to manage that.
>
> I don't expect ever to be able to download a bunch of data and have it
> all very fast on my screen.  But I do think that a system being always
> faster than the user gives the user an impression of total control,
> which is pleasurable.  So I would consider that a very nice improvement
> for Gnus itself.

The main issue is: if you get control of Emacs back right away, what
happens when the server response comes in? Work still needs to be done
to parse the response and incorporate it into Gnus' state, and that work
needs to be done in lisp, which means the user is probably going to get
interrupted again, to some extent. Let's see how Dick is handling it! :)