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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gemini Lasswell <gazally <at> runbox.com>
Cc: 32502 <at> debbugs.gnu.org, michael.albinus <at> gmx.de
Subject: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs
Date: Sun, 26 Aug 2018 17:12:42 +0300

> From: Gemini Lasswell <gazally <at> runbox.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  32502 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.