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

[Eli Zaretskii]

> From: Gemini Lasswell <gazally@runbox.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  32502@debbugs.gnu.org
> Date: Sat, 25 Aug 2018 14:53:24 -0700
> 
> (defun my-thread-func ()
>   (sleep-for 5)
>   (thread-signal main-thread 'error "message"))
> (make-thread #'my-thread-func)
> 
> Then, within 5 seconds, type C-x C-f.  Wait a few seconds.
> Result: Emacs aborts.
> 
> Emacs aborting in this case is arguably by design, not a bug.
> 
> But even if we change it so the main thread does not kill Emacs if
> signaled while waiting for input, signaling the main thread on a child
> thread error is still problematic from a user friendliness point of
> view.

Yes.  We could advise people not to do that, and we could ignore such
signals in the code.

> Instead, maybe find-file-with-threads should wrap its body with
> something similar to with-demoted-errors.

That is already happening, for some sense of "demoted-errors": a
non-main thread that hits a fatal signal simply dies in silence.

> Another thought is that the thread-last-error function is currently not
> very useful, because its caller has no way to tell which thread had the
> error, and if more than one thread has an error, only the most recent is
> saved.  An improvement would be to give it an optional argument, a
> thread, and have it return the error that made that thread inactive, if
> there was one.  (This could probably replace the recently added cleanup
> argument.)

We could indeed make the error bookkeeping more sphisticated.

> Then asynchronous find-file could make a list of the threads it starts,
> and start either a timer or another thread to periodically check that list
> of threads, look for those which recently became inactive and report any
> errors with 'message', or wait until all threads are done and print a
> summary of successes and failures.

I don't think this will work, at least not literally as described,
because (1) running timers in multithreaded environment is tricky --
you don't know which thread will run it, but more often that not it
will be the main thread; and (2) only one thread runs at any given
time, so making a thread that will periodically do something is not
simple, as there's no guarantee it will indeed run with the requested
periodicity.