bug#53877: 29.0.50; [PATCH] async Gnus/nnml

[Eric Abrahamsen]

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

> Eric Abrahamsen <eric@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