From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs 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 Message-ID: <8336v16wth.fsf@gnu.org> References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> <87efemp0yz.fsf@runbox.com> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1535293071 19374 195.159.176.226 (26 Aug 2018 14:17:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 26 Aug 2018 14:17:51 +0000 (UTC) Cc: 32502@debbugs.gnu.org, michael.albinus@gmx.de To: Gemini Lasswell Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Aug 26 16:17:47 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 1ftvrM-0004ru-9c for geb-bug-gnu-emacs@m.gmane.org; Sun, 26 Aug 2018 16:17:44 +0200 Original-Received: from localhost ([::1]:49268 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ftvtS-0006Xy-Hv for geb-bug-gnu-emacs@m.gmane.org; Sun, 26 Aug 2018 10:19:54 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60777) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ftvnr-0001WR-F3 for bug-gnu-emacs@gnu.org; Sun, 26 Aug 2018 10:14:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ftvnm-0000SZ-L7 for bug-gnu-emacs@gnu.org; Sun, 26 Aug 2018 10:14:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:56414) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ftvnm-0000ST-HC for bug-gnu-emacs@gnu.org; Sun, 26 Aug 2018 10:14:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ftvnm-0008UW-8v for bug-gnu-emacs@gnu.org; Sun, 26 Aug 2018 10:14:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Aug 2018 14:14:02 +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.153529278232567 (code B ref 32502); Sun, 26 Aug 2018 14:14:02 +0000 Original-Received: (at 32502) by debbugs.gnu.org; 26 Aug 2018 14:13:02 +0000 Original-Received: from localhost ([127.0.0.1]:33198 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ftvmo-0008TD-8B for submit@debbugs.gnu.org; Sun, 26 Aug 2018 10:13:02 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:39501) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ftvml-0008Sj-Rv for 32502@debbugs.gnu.org; Sun, 26 Aug 2018 10:13:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ftvmd-00083U-H5 for 32502@debbugs.gnu.org; Sun, 26 Aug 2018 10:12:54 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41196) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ftvmd-000838-Bm; Sun, 26 Aug 2018 10:12:51 -0400 Original-Received: from [176.228.60.248] (port=1344 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ftvmc-0000js-U6; Sun, 26 Aug 2018 10:12:51 -0400 In-reply-to: <87efemp0yz.fsf@runbox.com> (message from Gemini Lasswell on Sat, 25 Aug 2018 14:53:24 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:149756 Archived-At: > From: Gemini Lasswell > Cc: Eli Zaretskii , 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.