From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.bugs Subject: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs Date: Thu, 30 Aug 2018 09:19:04 +0200 Message-ID: <87va7swcd3.fsf@gmx.de> References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> <87efemp0yz.fsf@runbox.com> <8336v16wth.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1535614064 14386 195.159.176.226 (30 Aug 2018 07:27:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 30 Aug 2018 07:27:44 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Gemini Lasswell , 32502@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Aug 30 09:27:39 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 1fvHMg-0003cq-N7 for geb-bug-gnu-emacs@m.gmane.org; Thu, 30 Aug 2018 09:27:38 +0200 Original-Received: from localhost ([::1]:47434 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fvHOn-0002yz-1Y for geb-bug-gnu-emacs@m.gmane.org; Thu, 30 Aug 2018 03:29:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55385) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fvHOZ-0002tA-KW for bug-gnu-emacs@gnu.org; Thu, 30 Aug 2018 03:29:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fvHFK-0005Te-LK for bug-gnu-emacs@gnu.org; Thu, 30 Aug 2018 03:20:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:32833) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fvHFK-0005TY-HJ for bug-gnu-emacs@gnu.org; Thu, 30 Aug 2018 03:20:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fvHFK-0001A2-Bt for bug-gnu-emacs@gnu.org; Thu, 30 Aug 2018 03:20:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 30 Aug 2018 07:20: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.15356135594403 (code B ref 32502); Thu, 30 Aug 2018 07:20:02 +0000 Original-Received: (at 32502) by debbugs.gnu.org; 30 Aug 2018 07:19:19 +0000 Original-Received: from localhost ([127.0.0.1]:37851 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvHEc-00018w-Qa for submit@debbugs.gnu.org; Thu, 30 Aug 2018 03:19:19 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:47135) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvHEa-00018k-Cy for 32502@debbugs.gnu.org; Thu, 30 Aug 2018 03:19:16 -0400 Original-Received: from detlef.gmx.de ([212.91.238.173]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MA9FV-1g61nG0dIn-00BNmx; Thu, 30 Aug 2018 09:19:07 +0200 In-Reply-To: <8336v16wth.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 26 Aug 2018 17:12:42 +0300") X-Provags-ID: V03:K1:tUIkhgmdAtbVAGsNAZVyTHF3HRUeqMQFkVF15I9fmjd3JELHS1x v/uCtifKUEMbEgymZ77SfWgw1gQE4MkofrOvgqJ0B2Dl9ucOD7a2QXU0euYfD/+YKIamwJR SuXlQWBW/7s8Tp8Sb8LB6bTW+IZpq94WeBmWpu4feR6WDXZtBwusLPggHolgtun5on/1gcW FmBaK4iuGOglh7GsdAgNQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:GE38euesWG8=:xWyjR+k+VOfgFgSKVlqFAG ahT7LBrfUuGupi0mjAi0CBjGH2cXV4zgXT3HjUdPx7+KPIpONsR1u13+XxSyF21Z7NYNDn6a5 HLQCUYMjmGRWJLb2mYCFR7U3qZU16/5Pdq9wKk0N1IBqxGM6gfhtRQHmx9S7AQmiupgkBoolY QzoaYzeidEdOvKt4fUrV3HoLE79XWY24PQJqTsnRKErGnLlEN43+k27aEs2GZuLWdHuW3CTgu pb53Ku90orXrqc2IjRJbJskxy/kn4iKElclBZVACrNLNhJfTFrZadjNuumCvvtskwF/6GFLPB EXYxECmG2zmVvpLCrI5o8/R/nwlaPgLdTtu8QfgJe7xL6neP9l7xYq/i+ZoQ3+oi2+37Qoy0z MWESvMz9rKSjCxnUjdXqHU+Pn9sFWyHjzp9fN9GeNsaCy8jOKgCeZYRaF0zN0kE4+OuFXZBW/ clZucykMsTTTFMKqfw2JexcQjxOPxZ8JdZW3rCeD+G9Z1ElpT4BnjLFG0yuIpHt+gpypk4LEL eyQ6awfq7RiW+yPnnVbDrrXtyFUVlmzD54usSDcFrhlkoghNsbNvqRR5S4/DUwO+WLP6pdmk3 Y6q0Dy7EbabLgkelhV4ypAFZ2Bo4H1Ff9GnCRoR1Buff+C7ZIBZLl4X37LwRjNJY/Og9Dy7a4 Lo0OpbmppRndpreVjE419clIU4eeeyL1VjFg24ER8obPIEnGYBPyuRXn8VvC213LxNRvDz45P x5/oljkzQpyO9u4DKI0Y/8KhASsLCkuQ5AlWddCRk6QGKSogdfpto5F8dIDDG65vHWZ3aSQb 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:149859 Archived-At: Eli Zaretskii writes: >> 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. Instead of a timer, the asynchronous find-file could check for errors of the finished thread(s). A good point might be, when thread-join delivers the result(s). It was said earlier already (I believe), but I repeat it: thread-join should not only return the result, but should also propagate signals the thread has been trapped. It would be the responsibility of the calling code to ignore this information, or to propagate. Best regards, Michael.