On 16 December 2016 at 23:26, Eli Zaretskii wrote: > > From: Elias Mårtenson > > 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.