Re: Threading IO-bound functions

["Elias Mårtenson" <lokedhs@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1915 bytes --]

On 16 December 2016 at 23:26, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Elias Mårtenson <lokedhs@gmail.com>
> > Date: Thu, 15 Dec 2016 12:01:51 +0800
> >
> > The number one function that I call that sometimes hang for a
> significant amount of time is ‘gnus’. I decided to
> > try running it in a thread, and it worked surprisingly well. Initial
> loading of the messages can now be done in the
> > background.
>
> Beginner's luck ;-)
>

Oh for sure. I was also careful not to do anything that may upset it (like
running other gnus-functions at the same time).

The fact that my macro implements one lock per function only makes it
usable for single-operation functions. Gnus should probably a global lock
that ensures that only one Gnus function at a time is called. This issue
can't be limited to just Gnus, so perhaps Emacs should provide some
higher-level facility to implement this stuff.


> Did you try this in "emacs -nw"?  And without your Gnus
> customizations, which allow some shortcuts?  Half way through its
> initialization, Gnus asks a question, and then you get bug#25214.
>

I was using the GTK Emacs, and yes, if it asks a question, the entire Emacs
crashes is the most bizarre way.

My workaround is simply making sure that it doesn't interact with the user.


> > I'd like to have people's opinions on this strategy, and if it might be
> reasonable to default ‘gnus’ to do this when
> > run on Emacs versions with concurrency support.
>
> I think we need first to solve the above problem in some way.  Or
> change Gnus to not ask any questions from a background thread.
>

I think most questions are asked using ‘read-string’ or some variant like
‘completing-read’, right? At the very least, I think that concurrent Emacs
needs to make sure that the behaviour of these functions are well-defined
in the context of threading.

[-- Attachment #2: Type: text/html, Size: 2779 bytes --]