Any experience refreshing GNUS asynchronously?

I just started trying out nnreddit, a Reddit backend for GNUS. Out of the box, an refresh take around 3 minutes. I peeked into the source code of nnreddit and it seems that most of the time it spent is just `accept-process-output`. This should play well with cooperative threading. So out of curiosity, I tried (make-thread (lambda () (gnus-group-get-new-news)) "Gnus Get News") Guess what -- it works! It does the work in the background without blocking emacs, and update the `*Group*` buffer once it's done. Surprisingly I didn't find anything similar online. I wonder have anyone experimented similiar techiques with more heavy usage? I have no idea how robust this is -- I could be very lucky with nnreddit, its source code has a bunch of `with-mutex`. I guess that suggests it's written with concurrency in mind? But it doesn't really use any concurrency out of the box, really puzzling... P.S. I know the workaround of running multiple Emacsen, but I don't really like it, because I would no longer have one single Lisp image where interoperation between applications is as simple as a function call, or hacking into each other's variables...

The [`commercial-emacs`](https://github.com/commercial-emacs/commercial-emacs/#how-has-the-code-diverged-thus-far) does async `*Group*` buffer updates. For some time I've been naively overriding GNU Emacs' built-in `gnus` with `commercial-emacs`'s one and that worked quite well.

Gosh this looks so cool, a real async gnus… I'll try loading its gnus directory into my GNU Emacs and see how it goes.

Before getting async gnus to work, I had to work through two bugs in the C code, reported in: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36609 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49861 I prematurely acceded to the fix in bug#36609, but it hadn't. I continued to get occasional dead locks until Commercial Emacs put it another fix. This was over a year ago, but I don't think the threads logic has substantively changed in GNU Emacs.

Thanks for the insights and all the effort pushing Emacs forward. Yeah, it's a fragile hack, that works by merely hoping C core and Lisp dependencies don't diverge too much. FWIW, I have a couple of `nnimap` accounts setup with Gnus from `commercial-emacs` [`bd61a651d04d`](https://github.com/commercial-emacs/commercial-emacs/commit/bd61a651d04d59f859bbb6473c9d360e4a317e81) in GNU Emacs [`0a8e88fd83db`](https://github.com/commercial-emacs/commercial-emacs/commit/0a8e88fd83db5398d36064a7f87cff5b57da7284). I had to rule out [`syntax-ppss-invalidate-cache`](https://github.com/commercial-emacs/commercial-emacs/blob/bd61a651d04d59f859bbb6473c9d360e4a317e81/lisp/gnus/message.el#L3199) for `message-mode` to work. Now doing `gnus-group-get-new-news` in a `*Group*` buffer doesn't lock (nor deadlock yet) Emacs for me.

You could have posted your patches properly instead of dumping them in one big blob. E.g. one patch per change. Currently your changes are stuck in your fork and help nobody.

>Yeah, it's a fragile hack, that works by merely hoping C core and Lisp dependencies don't diverge too much. The problem was how he did send his changes, there as one big patch instead of a list of individual changes: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49065