bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs

[Michael Albinus]

Gemini Lasswell <gazally@runbox.com> writes:

Hi Gemini,

> The ability to quit multiple threads at once also seems useful to me.
>
> One possibility would be if you do something like this, to open up all
> your project files at once:
>
> C-x & C-x f /scp:server:project/worktree_a/*.el RET
>
> And then after you press RET, realize that you meant to type worktree_b
> instead.
>
> Or after you press RET, realize that your network connection is too slow
> for what you've asked Emacs to do, making you decide you'd like it to
> give up.
>
> Or each of the threads starts reporting the same error, and you realize
> none of them are going to work, and you want to make the error spam stop
> so you can fix the problem.
>
> Right now the "Checking vc-registered" phase of multi-threaded
> find-file hogs the global lock and makes Emacs unusable for a while if
> you are loading many files at once; maybe that, or some other package in
> your config which wasn't written with threading in mind and gets called
> by your find-file threads, makes Emacs slow and goes on for too long,
> and you want to make it stop so you can do something else.
>
> C-g is probably not the solution to these situations and I'm not sure
> what is, but it would be nice to have some way to resolve them besides
> restarting Emacs.

You could enhance your thread.el. In the list of threads, one could mark
threads, and send all of them the quit signal via a new command.

Likely, this should happen only if you are in the main thread. So we also
need a command which lets you switch to the main thread, wherever you
are. C-g could be good for this, but I don't know whether there are
undesired side effects.

Hmm, this is the bug report. Shall we discuss it on emacs-devel?

Best regards, Michael.