Re: Threading IO-bound functions

[Elias Mårtenson]

On 16 December 2016 at 23:26, Eli Zaretskii <address@hidden> wrote:

> From: Elias Mårtenson <address@hidden>
> 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.