GNU bug report logs - #53877
29.0.50; [PATCH] async Gnus/nnml

Previous Next

Package: emacs;

Reported by: Manuel Giraud <manuel <at> ledu-giraud.fr>

Date: Tue, 8 Feb 2022 14:23:01 UTC

Severity: wishlist

Found in version 29.0.50

Full log


View this message in rfc822 format

From: Eric Abrahamsen <eric <at> ericabrahamsen.net>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: 53877 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: bug#53877: 29.0.50; [PATCH] async Gnus/nnml
Date: Fri, 11 Feb 2022 09:53:12 -0800
Manuel Giraud <manuel <at> ledu-giraud.fr> writes:

> Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
>
> [...]
>
>> Are you sure the original approach won't work? If you set
>> `nnmail-article-buffer' locally within the thread function, it seems to
>> work okay. Is this not workable:
>
> Hi Eric,
>
> I was trying just something different. The process/sentinel seems like a
> good (established) way to do this in emacs without having to rely on
> handling threads yielding (when?). Maybe it won't be fruitful though 😅

Without having actually gone and written the code myself... my guess is
these two approaches will end up being pretty equivalent in design, only
the details will vary. You're going to launch several "things" in a loop
(the things being either threads, or processes+sentinels), then block
the rest of Emacs while you wait for all of the "things" to be done,
then carry on with main function execution.

Gnus is not set up for these "things" to return at random intervals, ie
we cannot "fire and forget". Not to mention that the "things" will block
Emacs while running elisp, but relinquish control while receiving
process output, which I think would lead to a kind of "stuttering"
responsiveness that would be more annoying than simply blocking Emacs
altogether. No matter which approach you take it will probably have to
wait for all the things to return before it continues, so the only
advantage is in being able to "layer" multiple process io and save a
little time there.

The Trio python library has a neat concept called nurseries, which
guarantees that multiple child threads all have to return before main
code execution continues, that might be interesting to look at:

https://trio.readthedocs.io/en/latest/reference-core.html#nurseries-and-spawning




This bug report was last modified 2 years and 282 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.