From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Gemini Lasswell Newsgroups: gmane.emacs.bugs 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 Message-ID: <87efemp0yz.fsf@runbox.com> References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1535234716 5869 195.159.176.226 (25 Aug 2018 22:05:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 25 Aug 2018 22:05:16 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux) Cc: 32502@debbugs.gnu.org To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Aug 26 00:05:12 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ftggC-0001Pk-05 for geb-bug-gnu-emacs@m.gmane.org; Sun, 26 Aug 2018 00:05:12 +0200 Original-Received: from localhost ([::1]:47211 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ftgiI-000558-9m for geb-bug-gnu-emacs@m.gmane.org; Sat, 25 Aug 2018 18:07:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55911) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ftgi3-0004wZ-I5 for bug-gnu-emacs@gnu.org; Sat, 25 Aug 2018 18:07:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ftgVO-0004ly-8P for bug-gnu-emacs@gnu.org; Sat, 25 Aug 2018 17:54:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:55778) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ftgVO-0004lp-48 for bug-gnu-emacs@gnu.org; Sat, 25 Aug 2018 17:54:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ftgVN-0005QH-UU for bug-gnu-emacs@gnu.org; Sat, 25 Aug 2018 17:54:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gemini Lasswell Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 25 Aug 2018 21:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 32502 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 32502-submit@debbugs.gnu.org id=B32502.153523401520810 (code B ref 32502); Sat, 25 Aug 2018 21:54:01 +0000 Original-Received: (at 32502) by debbugs.gnu.org; 25 Aug 2018 21:53:35 +0000 Original-Received: from localhost ([127.0.0.1]:60796 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ftgUw-0005PZ-LM for submit@debbugs.gnu.org; Sat, 25 Aug 2018 17:53:34 -0400 Original-Received: from aibo.runbox.com ([91.220.196.211]:54990) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ftgUu-0005PR-91 for 32502@debbugs.gnu.org; Sat, 25 Aug 2018 17:53:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=runbox.com; s=rbselector1; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From; bh=BgRgdAlZmmDWZLK39auQmTG18hTPuvfiYJQW9AlgPuc=; b=Et5o/u595CVmG5qDdAh6GZqF5c e76vPofEiFQ5i6m9EQqH3hyXAp4sw9Kb0KxZ2HNNxW5raMC1PXrTLvdEa0lZGacvjlaWe4uZUzpn/ VIxTdgyMv6GGLGPFOBQlprL2IYH+ld5egcq+VFZHtBS5X1GYeHxg6v5pbojh8cTQ4HrokzHrh/gBd DIeksiFdAdkie21Tae90cwxKidknpf216oSqG7dlRL3lJnmhwkzz3VmFv6SArmKSETb+n5EfXQ/qZ 58FOFk8xbeXIK/BOqI4mA8eJXOvJlYzWa3ljJBkaycwIJCcKUcjHdiYVW6JFbQAKaJ9gLB5ZmN4NI CrAXmo6A==; Original-Received: from [10.9.9.210] (helo=mailfront10.runbox.com) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1ftgUt-0000xw-1P; Sat, 25 Aug 2018 23:53:31 +0200 Original-Received: by mailfront10.runbox.com with esmtpsa (uid:179284 ) (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) id 1ftgUp-00041P-52; Sat, 25 Aug 2018 23:53:27 +0200 In-Reply-To: <87o9dqbtv5.fsf@gmx.de> (Michael Albinus's message of "Sat, 25 Aug 2018 12:53:02 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:149748 Archived-At: Hello Michael, Michael Albinus 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.