unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Gemini Lasswell <gazally@runbox.com>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: 32502@debbugs.gnu.org
Subject: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs
Date: Sat, 25 Aug 2018 14:53:24 -0700	[thread overview]
Message-ID: <87efemp0yz.fsf@runbox.com> (raw)
In-Reply-To: <87o9dqbtv5.fsf@gmx.de> (Michael Albinus's message of "Sat, 25 Aug 2018 12:53:02 +0200")

Hello Michael,

Michael Albinus <michael.albinus@gmx.de> writes:

> Tramp propagates all signals to the main thread, otherwise they are not
> visible. But this might be problematic for the quit signal.

Actually it's problematic for all signals.  I'm traveling this weekend
and came up with a no-network-required way to reproduce an Emacs
exit when the main thread is signaled:

Evaluate the following:

(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.  Imagine I'm somewhere with a slow network connection, and start
an asynchronous find-file.  I know the file is large, and it will take a
while, so I bring up a message buffer, type an email and C-c C-c, so the
main thread starts a network connection with my email server.  That
causes it to yield to the find-file thread, which encounters an error.
If that error is signaled to the main thread, it will interrupt the
sending of the message.

> I could not reproduce the problem myself, but this was said already by
> Gemini that it isn't easy. The following patch does not propagate the
> quit (and debug) signals do the main thread. Does it help?

I can try it on Monday when I return, but I'm thinking it's the wrong
approach. 

Instead, maybe find-file-with-threads should wrap its body with
something similar to with-demoted-errors.  I say similar because I'm not
sure the debug-on-error behavior is right for this case.

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.)

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.





  parent reply	other threads:[~2018-08-25 21:53 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-22 18:19 bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs Gemini Lasswell
2018-08-22 18:46 ` Eli Zaretskii
2018-08-22 19:08   ` Eli Zaretskii
2018-08-22 19:23     ` Michael Albinus
2018-08-25 10:53     ` Michael Albinus
2018-08-25 12:42       ` Eli Zaretskii
2018-08-25 15:52         ` Michael Albinus
2018-08-25 16:07           ` Eli Zaretskii
2018-08-26 13:50             ` Gemini Lasswell
2018-08-30  9:24               ` Michael Albinus
2018-08-30 13:23                 ` Eli Zaretskii
2018-08-30 13:28                   ` Michael Albinus
2018-08-25 21:53       ` Gemini Lasswell [this message]
2018-08-26 14:12         ` Eli Zaretskii
2018-08-30  7:19           ` Michael Albinus
2018-08-30 12:34             ` Michael Albinus
2018-08-29 16:01         ` Michael Albinus
2018-08-29 16:23           ` Eli Zaretskii
2018-08-29 16:46             ` Michael Albinus
2018-08-29 17:03               ` Eli Zaretskii
2018-08-29 17:15                 ` Michael Albinus
2018-08-29 20:22                   ` Michael Albinus
2018-08-29 20:57                     ` Michael Albinus
2018-08-30  2:36                       ` Eli Zaretskii
2018-08-30  7:09                         ` Michael Albinus
2018-08-30 13:18                           ` Eli Zaretskii
2018-08-30 13:32                             ` Michael Albinus
2018-08-30 13:51                               ` Eli Zaretskii
2018-08-30 13:59                                 ` Michael Albinus
2018-08-30 16:48                                   ` Michael Albinus
2018-08-30 17:44                                     ` Eli Zaretskii
2018-08-30 19:30                                       ` Michael Albinus
2018-09-02 17:58                                         ` Michael Albinus
2018-09-02 20:03                                           ` Gemini Lasswell
2018-09-02 20:50                                             ` Michael Albinus
2018-08-30 19:29                                     ` Gemini Lasswell
2018-08-30 19:37                                       ` Michael Albinus
2018-08-31  6:52                                       ` Eli Zaretskii
2018-08-31 15:07                                         ` Gemini Lasswell
2018-08-31 17:45                                           ` Eli Zaretskii
2018-08-22 21:12   ` Gemini Lasswell
2018-08-23 14:01     ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87efemp0yz.fsf@runbox.com \
    --to=gazally@runbox.com \
    --cc=32502@debbugs.gnu.org \
    --cc=michael.albinus@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).