Re: async Gnus

[Manuel Giraud]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Manuel Giraud <manuel@ledu-giraud.fr> writes:
>
>> Hi,

Hi Eric,

>> I'd like to have Gnus being able to fetch some mails (and news
>> obviously ;-) without freezing emacs completely. I'm currently
>> trying the attached dumb patch that so far seems to fly with a gnus
>> demon handler like this:
>>
>> (gnus-demon-add-handler 'gnus-group-get-new-news 5 nil)
>>
>> My questions are:
>>
>>    - Is this the right place to discuss Gnus dev?
>
> Yes!

Good!

>>    - This patch seems too simple: what am I missing?
>
> It's hard to say -- no one seems to know what to expect with threads.
> The main issue I can see with your code is that it only uses a single
> thread, which should mean (I haven't tested it) that it provides very
> little speedup. All elisp execution happens in the main thread, the only
> concurrency happens with network and process communication (maybe some
> other stuff), so unless you're "layering" multiple process calls in
> multiple threads, everything's going to happen more or less
> consecutively anyway. I think you'd need one thread per Gnus server, so
> that multiple connections to external servers (IMAP or NNTP or POP)
> could do their thing concurrently.
>
> All this is just my theoretical understanding of how threads work, mind
> you. Have you seen a significant speedup with this patch?

I'm not looking for speedup I'm looking for being able to use Emacs as
usual while Gnus is fetching stuff. But you are right that this patch
does not achieve this: Emacs is still freezing from time to time and so
it is not really better than the default Gnus demon behaviour.

I'm suprprise: I thought that `make-thread' create a proper system
thread.

I'm digging into Gnus sources and also conclude that those threads
should appear at a deeper layer (maybe at the method request layer or
per Gnus server as you said). It would also permit concurrency between
methods (or servers).

I should also keep in mind that this could fallback to a non-threaded
method for arch that do not have them.

> Also, bug#49065 might have some relevant code you could refer to, I
> think the author was trying to do something similar there.

Thanks, I'll have a look at it!
-- 
Manuel Giraud