From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 22 14:25:15 2018 Received: (at submit) by debbugs.gnu.org; 22 Aug 2018 18:25:15 +0000 Received: from localhost ([127.0.0.1]:57969 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fsXog-0000lS-Uz for submit@debbugs.gnu.org; Wed, 22 Aug 2018 14:25:15 -0400 Received: from eggs.gnu.org ([208.118.235.92]:43042) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fsXof-0000lD-87 for submit@debbugs.gnu.org; Wed, 22 Aug 2018 14:25:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fsXoY-0002e9-MS for submit@debbugs.gnu.org; Wed, 22 Aug 2018 14:25:08 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:56883) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fsXoY-0002dr-A6 for submit@debbugs.gnu.org; Wed, 22 Aug 2018 14:25:06 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35659) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fsXoU-0000Wa-RY for bug-gnu-emacs@gnu.org; Wed, 22 Aug 2018 14:25:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fsXjK-0000Wu-TM for bug-gnu-emacs@gnu.org; Wed, 22 Aug 2018 14:19:46 -0400 Received: from aibo.runbox.com ([91.220.196.211]:38630) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fsXjK-0000Vp-Hv for bug-gnu-emacs@gnu.org; Wed, 22 Aug 2018 14:19:42 -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:Date:Subject:To:From; bh=kQelJFvUkDkauDkCxeNZX2jxglH2rOvY9cZVVtr6R04=; b=pUGSz7mV5/hJg+0zWESZHQvLp YtIxwjB9vPlMh1ceIDwbKc9iel9MPobW1Ui8vGvwb4SKBbV5W4N5VELBHbi91ZPQBYdOo4Q2aj83V gemAGGZeoXmiI0T9BkBTIrqGvOdR+zB1+31/2D0+J9z3jw0SiRcXzz2VyeKaLwH0sI3R7FbckiaMF TlhrRrrEfbM5HClbsWyoJSdKqqM7Eq4ifmVnEDcYwfXMm3l1y5DS9pKX/sMAHK8tNSLGZ8MTP7vYC xtVZaGIyRVHxLunvMz2P60XGgWDPngJ1zyMSEuw1rOEwzkQCIgfWz3UV4/pAJ48ufJwD+uWmXtk28 d4PNzk6SQ==; Received: from [10.9.9.210] (helo=mailfront10.runbox.com) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1fsXjH-0004HV-W6 for bug-gnu-emacs@gnu.org; Wed, 22 Aug 2018 20:19:40 +0200 Received: by mailfront10.runbox.com with esmtpsa (uid:179284 ) (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) id 1fsXjE-000113-IG for bug-gnu-emacs@gnu.org; Wed, 22 Aug 2018 20:19:37 +0200 From: Gemini Lasswell To: bug-gnu-emacs@gnu.org Subject: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs Date: Wed, 22 Aug 2018 11:19:34 -0700 Message-ID: <87mutep8ll.fsf@runbox.com> MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.1 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.1 (-----) This bug report is against the feature/tramp-thread-safe branch, 162353c45c. C-g typed while Tramp is opening multiple remote files asynchronously will sometimes cause Emacs to abort. It's probably dependent on the timing of the C-g, and seems to either happen the first time I try C-g or not at all. I'm typing C-g fairly soon after RET, but not as fast as I possibly could. The remote machine is on the local network and I'm running Emacs on a laptop with a wireless network connection. So far I've reproduced the bug twice in about 8 attempts. I currently have it in the debugger. To reproduce, with emacs -Q and the Emacs source tree stored on a remote machine: C-x & C-x C-f /scp:server:src/emacs/lisp/emacs-lisp/*.el RET C-g Result: #0 terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=40) at emacs.c:368 #1 0x0000000000511833 in emacs_abort () at sysdep.c:2426 #2 0x000000000057114d in signal_or_quit (error_symbol=XIL(0xaaa0), data=XIL(0), keyboard_quit=keyboard_quit@entry=false) at eval.c:1612 #3 0x000000000057115b in Fsignal (error_symbol=, data=) at eval.c:1582 #4 0x00000000005d5555 in post_acquire_global_lock (self=self@entry=0xc19320 ) at thread.c:93 #5 0x00000000005d578a in acquire_global_lock (self=0xc19320 ) at thread.c:101 #6 really_call_select (arg=0x7ffe202d8ab0) at thread.c:582 #7 0x00000000005d64e9 in thread_select (func=, max_fds=max_fds@entry=11, rfds=rfds@entry=0x7ffe202d8b90, wfds=, efds=efds@entry=0x0, timeout=timeout@entry=0x7ffe202d91b0, sigmask=0x0) at thread.c:602 #8 0x00000000005f1f44 in xg_select (fds_lim=11, rfds=rfds@entry=0x7ffe202d92b0, wfds=wfds@entry=0x7ffe202d9330, efds=efds@entry=0x0, timeout=timeout@entry=0x7ffe202d91b0, sigmask=sigmask@entry=0x0) at xgselect.c:117 #9 0x00000000005b7328 in wait_reading_process_output (time_limit=time_limit@entry=30, nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1, do_display=do_display@entry=true, wait_for_cell=wait_for_cell@entry=XIL(0), wait_proc=wait_proc@entry=0x0, just_wait_proc=0) at process.c:5384 #10 0x0000000000424000 in sit_for (timeout=, reading=reading@entry=true, display_option=display_option@entry=1) at dispnew.c:5801 #11 0x00000000005042c6 in read_char (commandflag=commandflag@entry=1, map=map@entry=XIL(0x4d90c43), prev_event=XIL(0), used_mouse_menu=used_mouse_menu@entry=0x7ffe202d9bab, end_time=end_time@entry=0x0) at keyboard.c:2688 #12 0x000000000050491b in read_key_sequence (keybuf=keybuf@entry=0x7ffe202d9ce0, prompt=prompt@entry=XIL(0), dont_downcase_last=dont_downcase_last@entry=false, can_return_switch_frame=can_return_switch_frame@entry=true, fix_current_buffer=fix_current_buffer@entry=true, prevent_redisplay=prevent_redisplay@entry=false) at keyboard.c:9108 #13 0x00000000005062fa in command_loop_1 () at keyboard.c:1338 #14 0x000000000056f6ef in internal_condition_case (bfun=bfun@entry=0x506100 , handlers=handlers@entry=XIL(0x5340), hfun=hfun@entry=0x4fae20 ) at eval.c:1349 #15 0x00000000004f77e8 in command_loop_2 (ignore=ignore@entry=XIL(0)) at keyboard.c:1079 #16 0x000000000056f653 in internal_catch (tag=tag@entry=XIL(0xc990), func=func@entry=0x4f77c0 , arg=arg@entry=XIL(0)) at eval.c:1114 #17 0x00000000004f7776 in command_loop () at keyboard.c:1058 #18 0x00000000004faa0f in recursive_edit_1 () at keyboard.c:703 #19 0x00000000004fad48 in Frecursive_edit () at keyboard.c:774 #20 0x000000000041a353 in main (argc=, argv=0x7ffe202da098) at emacs.c:1756 In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.28) of 2018-08-21 built on sockeye Repository revision: 162353c45cf7ae8c5626a5062c247a793e30e7d0 Windowing system distributor 'The X.Org Foundation', version 11.0.11906000 System Description: NixOS 18.03.git.bd06547 (Impala) Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. Configured using: 'configure --prefix=/home/gem/src/emacs/tramp/bin --with-modules --with-x-toolkit=gtk3 --with-xft --config-cache' Configured features: XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GSETTINGS NOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 MODULES THREADS LCMS2 GMP Important settings: value of $EMACSLOADPATH: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv bytecomp byte-compile cconv dired dired-loaddefs format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils elec-pair time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads dbusbind inotify lcms2 dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 94963 7770) (symbols 48 20145 1) (strings 32 28303 1519) (string-bytes 1 756774) (vectors 16 14934) (vector-slots 8 508714 14278) (floats 8 48 69) (intervals 56 208 0) (buffers 992 11)) From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 22 14:47:02 2018 Received: (at 32502) by debbugs.gnu.org; 22 Aug 2018 18:47:02 +0000 Received: from localhost ([127.0.0.1]:57980 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fsY9m-0001IX-8a for submit@debbugs.gnu.org; Wed, 22 Aug 2018 14:47:02 -0400 Received: from eggs.gnu.org ([208.118.235.92]:47720) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fsY9j-0001ID-Ha for 32502@debbugs.gnu.org; Wed, 22 Aug 2018 14:46:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fsY9a-0003ki-7d for 32502@debbugs.gnu.org; Wed, 22 Aug 2018 14:46:54 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39141) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fsY9a-0003kd-33; Wed, 22 Aug 2018 14:46:50 -0400 Received: from [176.228.60.248] (port=3540 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fsY9Z-0002ew-NF; Wed, 22 Aug 2018 14:46:50 -0400 Date: Wed, 22 Aug 2018 21:46:42 +0300 Message-Id: <83o9dub5nx.fsf@gnu.org> From: Eli Zaretskii To: Gemini Lasswell In-reply-to: <87mutep8ll.fsf@runbox.com> (message from Gemini Lasswell on Wed, 22 Aug 2018 11:19:34 -0700) Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 32502 Cc: 32502@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: Gemini Lasswell > Date: Wed, 22 Aug 2018 11:19:34 -0700 > > To reproduce, with emacs -Q and the Emacs source tree stored on a remote > machine: > > C-x & C-x C-f /scp:server:src/emacs/lisp/emacs-lisp/*.el RET > C-g > > Result: > > #0 terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=40) at emacs.c:368 > #1 0x0000000000511833 in emacs_abort () at sysdep.c:2426 > #2 0x000000000057114d in signal_or_quit (error_symbol=XIL(0xaaa0), data=XIL(0), keyboard_quit=keyboard_quit@entry=false) at eval.c:1612 In frame #2, which one of these 2 conditions caused the abort: if (gc_in_progress || waiting_for_input) emacs_abort (); > #3 0x000000000057115b in Fsignal (error_symbol=, data=) at eval.c:1582 > #4 0x00000000005d5555 in post_acquire_global_lock (self=self@entry=0xc19320 ) at thread.c:93 And in frame #4, what is current_thread->error_symbol? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 22 15:09:00 2018 Received: (at 32502) by debbugs.gnu.org; 22 Aug 2018 19:09:00 +0000 Received: from localhost ([127.0.0.1]:57995 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fsYV0-0001pO-DU for submit@debbugs.gnu.org; Wed, 22 Aug 2018 15:09:00 -0400 Received: from eggs.gnu.org ([208.118.235.92]:52445) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fsYUz-0001pC-2Z for 32502@debbugs.gnu.org; Wed, 22 Aug 2018 15:08:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fsYUq-0000TO-Sc for 32502@debbugs.gnu.org; Wed, 22 Aug 2018 15:08:52 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39525) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fsYUq-0000TI-PE; Wed, 22 Aug 2018 15:08:48 -0400 Received: from [176.228.60.248] (port=1149 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fsYUq-0003po-C8; Wed, 22 Aug 2018 15:08:48 -0400 Date: Wed, 22 Aug 2018 22:08:40 +0300 Message-Id: <83muteb4nb.fsf@gnu.org> From: Eli Zaretskii To: Michael Albinus In-reply-to: <83o9dub5nx.fsf@gnu.org> (message from Eli Zaretskii on Wed, 22 Aug 2018 21:46:42 +0300) Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 32502 Cc: gazally@runbox.com, 32502@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > Date: Wed, 22 Aug 2018 21:46:42 +0300 > From: Eli Zaretskii > Cc: 32502@debbugs.gnu.org > > > #3 0x000000000057115b in Fsignal (error_symbol=, data=) at eval.c:1582 > > #4 0x00000000005d5555 in post_acquire_global_lock (self=self@entry=0xc19320 ) at thread.c:93 > > And in frame #4, what is current_thread->error_symbol? Michael, unless I'm missing something, it sounds like Tramp signals the main thread in this scenario. (current_thread->error_symbol is only set by thread-signal.) Is that really necessary? If so, can you describe why you needed to signal the main thread, while it was waiting for input? From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 22 15:24:09 2018 Received: (at 32502) by debbugs.gnu.org; 22 Aug 2018 19:24:09 +0000 Received: from localhost ([127.0.0.1]:58032 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fsYjh-0002FO-5N for submit@debbugs.gnu.org; Wed, 22 Aug 2018 15:24:09 -0400 Received: from mout.gmx.net ([212.227.17.22]:53371) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fsYjf-0002Ev-BZ for 32502@debbugs.gnu.org; Wed, 22 Aug 2018 15:24:07 -0400 Received: from detlef.gmx.de ([212.91.243.91]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MLelb-1fspyw3eQl-000u81; Wed, 22 Aug 2018 21:23:58 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> Date: Wed, 22 Aug 2018 21:23:56 +0200 In-Reply-To: <83muteb4nb.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 22 Aug 2018 22:08:40 +0300") Message-ID: <87a7peciib.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:LUQt//1/5x4lCtKG/5/IPkn2Q3b2M3LPF/7A+kYlYnjiZv/4ftw GvOn1bsl8j9+kJMsPgg4LlUXPmXzpKDNw4bj2unKwE5vC+J6ed3byd5y0TRx+hy8tXg2Jsd T5LGsd6NQbASn/cWo+0IeAzf1RvFiR6RIg2cQwUHuCIJCU/86J/lJUMYme4RVlxR+j+qrf/ Y61RAf21CCsUBO3gY+LYQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:sYGYBWRqwBQ=:Wvhwu6laL+2V8BdpzfRAWz Te+ur0SoKrQGhIGaJwQkKNznHk8ZeWyUzOose5I4Mm4xP+lHPleMMK0ypDu9gDtQgx+rzcpYp 9foBJf/28Zi6DuX1ZR24NLrRh/d26hCO4wA15LCwynjgB7TzCdf7U9kT4OPrCPwhxKDlMg3JL /GDSUaZtGJOcZn9w/QyZX0bZyr8IC86HRGa7F39zJWxh/7I6V/mZ9Y7xmi77FbjEHkhIsmkNb WhMzi6RfPAxvSlpVGe1razPZlxMJ6gKceMg19zmDIEg9imI+2GG3sKWluJegpucnF2mtMTTwi B21YdNR8EAFpNx6RDqW2wqHnxNBs7pzkk3H7lamTERCaOiMfe6NWzmEBq0hXCVSNss5TREQK4 D3A6+9LInDvvwoaCK5CNgFc6mzgbHUBMvxCQw1/zWxcXZQ5aOdpup2oT6ty+ieE4ZmA8FlT0t xIwa+TNgbZnMm49DpBTpeNwgb3qI0xhqra37zSw2ukfRXZukHnwfmmiML8MsWEIBu0yNqsciO esahf9rnmaZm7WJoNdXRM+gmW6YF2H8Eo40LbKQPUSzLo0Zbqzqbr91fzOAJUZZdgMNXIlsBA HRPW4quoWKhy4d43DLwwGdgn47/yLaCSjwp8iOKfQM1E3qUxQXDBmeB/KGc7tYU4SD6DA6vc4 Xx0ra/b2oZYuKB7wnDc6wxwymBH0lv0cEQvL4gd/70w+3vFAOV2cDB8v9oLZo3lcKvifBO4FB x0H3feGBCxjS19y0AxzjxQbzjf2bmo57QZ8QSGEnIQCeMKvMKbnVXmhgp37bFx8+0QRWVa3IT nFghOxF X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 32502 Cc: gazally@runbox.com, 32502@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: Hi Eli, > Michael, unless I'm missing something, it sounds like Tramp signals > the main thread in this scenario. (current_thread->error_symbol is > only set by thread-signal.) Is that really necessary? If so, can you > describe why you needed to signal the main thread, while it was > waiting for input? Will work on this over the weekend, there's no time left until. Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 22 17:12:35 2018 Received: (at 32502) by debbugs.gnu.org; 22 Aug 2018 21:12:35 +0000 Received: from localhost ([127.0.0.1]:58096 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fsaQd-0005Bb-CA for submit@debbugs.gnu.org; Wed, 22 Aug 2018 17:12:35 -0400 Received: from aibo.runbox.com ([91.220.196.211]:46000) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fsaQa-0005BR-VK for 32502@debbugs.gnu.org; Wed, 22 Aug 2018 17:12: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=xbwA2jZtUW63RaDzGAfsmMyDdF3MZ2TSHH0ncOUjH9E=; b=VlUAmzGZqHvKOliao8xFmRDy6V HJnbOnrBVoKIFtH0Itog1Qz0Y+vT7bQEFRvbjEIJYe+rWu4kMA1M0vqTAFm+j2wDUyGM1FX2Uxwh2 axd3IN1aczGGlahTu8E8ymqaTWENKC5bwdkU+ExewSHzC1Fim1zCOAHXmxw/MrwI2qbK0Qlrm9dgK VXGFBipCU+YktxDSgOLUaTAwL1vnqbBtgfeAmqmCMGSeTr0jIPoWIM2+ZTa/d4+sodLZ9MILnM85U JmoK/838ZHJeJKTpxsqEm7J5ojFHo29VwHdK1WxDo+nXk6AuWP571bzeGgwsaOrquaURhKVLYc0b6 icbSkwXA==; Received: from [10.9.9.210] (helo=mailfront10.runbox.com) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1fsaQZ-0001ZS-MT; Wed, 22 Aug 2018 23:12:31 +0200 Received: by mailfront10.runbox.com with esmtpsa (uid:179284 ) (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) id 1fsaQO-0004wP-Nz; Wed, 22 Aug 2018 23:12:21 +0200 From: Gemini Lasswell To: Eli Zaretskii Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> Date: Wed, 22 Aug 2018 14:12:18 -0700 In-Reply-To: <83o9dub5nx.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 22 Aug 2018 21:46:42 +0300") Message-ID: <87in42p0lp.fsf@runbox.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 32502 Cc: 32502@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: > In frame #2, which one of these 2 conditions caused the abort: > > if (gc_in_progress || waiting_for_input) > emacs_abort (); > And in frame #4, what is current_thread->error_symbol? > > Thanks. (gdb) p gc_in_progress $1 = false (gdb) p waiting_for_input $2 = true (gdb) up 4 #4 0x00000000005d5555 in post_acquire_global_lock (self=self@entry=0xc19320 ) at thread.c:93 93 Fsignal (sym, data); (gdb) p current_thread->error_symbol $3 = XIL(0) (gdb) pr (gdb) pp current_thread->error_symbol (gdb) p current_thread->error_symbol $4 = XIL(0) (gdb) xpr Lisp_Symbol $5 = (struct Lisp_Symbol *) 0xbf5420 "nil" From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 23 10:02:02 2018 Received: (at 32502) by debbugs.gnu.org; 23 Aug 2018 14:02:02 +0000 Received: from localhost ([127.0.0.1]:58964 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fsqBV-00058o-VN for submit@debbugs.gnu.org; Thu, 23 Aug 2018 10:02:02 -0400 Received: from eggs.gnu.org ([208.118.235.92]:33033) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fsqBU-00058K-A5 for 32502@debbugs.gnu.org; Thu, 23 Aug 2018 10:02:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fsqBJ-0003eJ-AG for 32502@debbugs.gnu.org; Thu, 23 Aug 2018 10:01:54 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34203) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fsqBJ-0003eB-5k; Thu, 23 Aug 2018 10:01:49 -0400 Received: from [176.228.60.248] (port=4398 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fsqBI-0007Kl-OW; Thu, 23 Aug 2018 10:01:49 -0400 Date: Thu, 23 Aug 2018 17:01:34 +0300 Message-Id: <838t4xb2rl.fsf@gnu.org> From: Eli Zaretskii To: Gemini Lasswell In-reply-to: <87in42p0lp.fsf@runbox.com> (message from Gemini Lasswell on Wed, 22 Aug 2018 14:12:18 -0700) Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <87in42p0lp.fsf@runbox.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 32502 Cc: 32502@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: Gemini Lasswell > Cc: 32502@debbugs.gnu.org > Date: Wed, 22 Aug 2018 14:12:18 -0700 > > Eli Zaretskii writes: > > > In frame #2, which one of these 2 conditions caused the abort: > > > > if (gc_in_progress || waiting_for_input) > > emacs_abort (); > > > And in frame #4, what is current_thread->error_symbol? > > > > Thanks. > > (gdb) p gc_in_progress > $1 = false > (gdb) p waiting_for_input > $2 = true > (gdb) up 4 > #4 0x00000000005d5555 in post_acquire_global_lock (self=self@entry=0xc19320 ) at thread.c:93 > 93 Fsignal (sym, data); > (gdb) p current_thread->error_symbol > $3 = XIL(0) > (gdb) pr > (gdb) pp current_thread->error_symbol > (gdb) p current_thread->error_symbol > $4 = XIL(0) > (gdb) xpr > Lisp_Symbol > $5 = (struct Lisp_Symbol *) 0xbf5420 > "nil" Thanks. So my assumption was true: the main thread is signaled while waiting for input. Perhaps we should disallow that. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 25 06:53:14 2018 Received: (at 32502) by debbugs.gnu.org; 25 Aug 2018 10:53:14 +0000 Received: from localhost ([127.0.0.1]:60229 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ftWBu-0004Qr-IQ for submit@debbugs.gnu.org; Sat, 25 Aug 2018 06:53:14 -0400 Received: from mout.gmx.net ([212.227.17.20]:44581) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ftWBs-0004Qd-6Q for 32502@debbugs.gnu.org; Sat, 25 Aug 2018 06:53:12 -0400 Received: from detlef.gmx.de ([213.220.149.148]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M2cDB-1fcwi51T1R-00sJn4; Sat, 25 Aug 2018 12:53:04 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> Date: Sat, 25 Aug 2018 12:53:02 +0200 In-Reply-To: <83muteb4nb.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 22 Aug 2018 22:08:40 +0300") Message-ID: <87o9dqbtv5.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Provags-ID: V03:K1:hpqm+YxRKHX6bWq6mn3oK14F3fZv62LIEshPqo1IrtwfgpyNLEp zJVLd1I11ZkVGLB52W/OB+t9mYB2/k15AiEG5KmGRB84UKneGPN/odJIGqpxFCh2bqAbTFS vJ0H8O5dCMlc30NVwGx3MC2NqY78b/PieazwsZijAHG7DgN+3kNjM9NlSC/N0cyZrX3oxe1 nOR8zJORdxrnmiogXTLww== X-UI-Out-Filterresults: notjunk:1;V01:K0:juEGwzWn3ps=:CRJc2jQrveoRI5sQ1gO+FR 97qVpMbVY4E6nw8LEo253PzmILptI1SmEZKSuyN2378wuinvtnAhhRBu3HRfKcYbe6dRu+dzq jHGCPamcL0JLtt4NSsB2Pt6d2KwpLuaCDlhdMb/bvrqAGG2Ad8f29rSeeMHMTKvkLPnxhyUAA 2XurdxKYY2JSgBnEqSTdjh/kVasdUHNnB9ZjfcF7qdWkAkF7thyzrAcKNqpgHB6Z7h9Mz8UzL ZeebnyUpREqXfh9cOkt3Azw14coP9S8cAdyMC8Kl4OpcWs8m7xywK2ZpS3yslgK1v+gY6HuQF uGB+CA/g1NjdHqjj9qwPYGWDvOdN+O4O3RpX9d/b3h76inVy34trgFevA4w/HINvU1IjX4jQM 41NtXB0GP3euHQvwgwTh/ijIaPV7KhLL1E4MZxX873JahzgUP/5ZpxPg47RTPFV93WhtEbVSB rrIWZgLWVIYrq0UJMEQ1TQOpU7Be6f599g6j+X5SnixNqiueWhstwhyYWyY+wklmrbXYLr3Au n9M8RKPdd6K/XJjT9fyHuZLulzzGuy2QNiQFMjZVNPRvugZPoc0TrZEuGsHH18bg5pQ9/v5gz TdvqsgIv6z/Ga35XcXw3UT/N/JSp3ctgFgkrTCImW9u3EaXXMg4A4EB8wYBuXw4Rg8QZKYogr vVfjug3iqB6W8Yi2Pb3wO3MS5BOpYRsEZtFUI39HN7Q96FF8EzDjoRWnDvIfPFMBm7efx1VMB c7SFYJH//E1uAU2WSXm+rLbXFv68uH5pAY8R+RAqwgh9A7Xy4Kz+qu+a1M0= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 32502 Cc: gazally@runbox.com, 32502@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --=-=-= Content-Type: text/plain Eli Zaretskii writes: Hi Eli, >> > #3 0x000000000057115b in Fsignal (error_symbol=, >> > data=) at eval.c:1582 >> > #4 0x00000000005d5555 in post_acquire_global_lock >> > (self=self@entry=0xc19320 ) at thread.c:93 >> >> And in frame #4, what is current_thread->error_symbol? > > Michael, unless I'm missing something, it sounds like Tramp signals > the main thread in this scenario. (current_thread->error_symbol is > only set by thread-signal.) Is that really necessary? If so, can you > describe why you needed to signal the main thread, while it was > waiting for input? Tramp propagates all signals to the main thread, otherwise they are not visible. But this might be problematic for the quit signal. 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? However, if we apply this I don't know how to quit (let's say) 250 threads. One quit signal is good for one thread only. I believe we need also a mechanism to quit many threads at once. Best regards, Michael. --=-=-= Content-Type: text/plain Content-Disposition: attachment diff --git a/lisp/tramp.el b/lisp/tramp.el index c913640e..3a09674c 100644 --- a/lisp/tramp.el +++ b/lisp/tramp.el @@ -2342,8 +2342,9 @@ If Emacs is compiled --with-threads, the body is protected by a mutex." (tramp-message v 1 "Interrupt received in operation %s" (cons operation args))) - ;; Propagate the quit signal. - (tramp-compat-signal (car err) (cdr err))) + ;; Propagate the signal. We do not want this + ;; to go to the main thread. + (signal (car err) (cdr err))) ;; When we are in completion mode, some failed ;; operations shall return at least a default @@ -2361,7 +2362,7 @@ If Emacs is compiled --with-threads, the body is protected by a mutex." (memq operation '(expand-file-name file-name-as-directory))) filename) - ;; Propagate the error. + ;; Propagate the error to the main thread. (t (tramp-compat-signal (car err) (cdr err)))))) ;; Nothing to do for us. However, since we are in --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 25 08:43:09 2018 Received: (at 32502) by debbugs.gnu.org; 25 Aug 2018 12:43:09 +0000 Received: from localhost ([127.0.0.1]:60261 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ftXuG-0000ls-QH for submit@debbugs.gnu.org; Sat, 25 Aug 2018 08:43:09 -0400 Received: from eggs.gnu.org ([208.118.235.92]:42321) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ftXuE-0000lM-ES for 32502@debbugs.gnu.org; Sat, 25 Aug 2018 08:43:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ftXu4-00054x-VN for 32502@debbugs.gnu.org; Sat, 25 Aug 2018 08:43:01 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45978) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ftXu4-00054p-Qp; Sat, 25 Aug 2018 08:42:56 -0400 Received: from [176.228.60.248] (port=2797 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ftXu4-00063P-9y; Sat, 25 Aug 2018 08:42:56 -0400 Date: Sat, 25 Aug 2018 15:42:45 +0300 Message-Id: <83pny67h2y.fsf@gnu.org> From: Eli Zaretskii To: Michael Albinus In-reply-to: <87o9dqbtv5.fsf@gmx.de> (message from Michael Albinus on Sat, 25 Aug 2018 12:53:02 +0200) Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 32502 Cc: gazally@runbox.com, 32502@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: Michael Albinus > Cc: gazally@runbox.com, 32502@debbugs.gnu.org > Date: Sat, 25 Aug 2018 12:53:02 +0200 > > > Michael, unless I'm missing something, it sounds like Tramp signals > > the main thread in this scenario. (current_thread->error_symbol is > > only set by thread-signal.) Is that really necessary? If so, can you > > describe why you needed to signal the main thread, while it was > > waiting for input? > > Tramp propagates all signals to the main thread, otherwise they are not > visible. Is that wise? It means that if a user is doing something in the main thread while the Tramp threads run asynchronously, the user's program will/might error out. > However, if we apply this I don't know how to quit (let's say) 250 > threads. One quit signal is good for one thread only. I believe we need > also a mechanism to quit many threads at once. I think we should simply make thread-signal a no-op when it signals the main thread during the time the main thread is waiting for input. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 25 11:52:48 2018 Received: (at 32502) by debbugs.gnu.org; 25 Aug 2018 15:52:48 +0000 Received: from localhost ([127.0.0.1]:60724 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ftaro-0005Q4-0i for submit@debbugs.gnu.org; Sat, 25 Aug 2018 11:52:48 -0400 Received: from mout.gmx.net ([212.227.17.22]:35651) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ftarl-0005Pp-NF for 32502@debbugs.gnu.org; Sat, 25 Aug 2018 11:52:46 -0400 Received: from detlef.gmx.de ([213.220.149.148]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lw2dd-1fsENk2t4v-017l9t; Sat, 25 Aug 2018 17:52:37 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> <83pny67h2y.fsf@gnu.org> Date: Sat, 25 Aug 2018 17:52:34 +0200 In-Reply-To: <83pny67h2y.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 25 Aug 2018 15:42:45 +0300") Message-ID: <8736v2bfzx.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:I/kIzQmKoRpl29nagUtImktXxqXhbMfSM6oAJ+kPVALswfPsism 09WREMcUhFp34UzG0bwmVf7laBoLwnYkqBtyymcBWwdLMkB7q7MxXAs5XQD5YYp1+OTqMSA Vyp1pWQ6056Of69l48ANMXxosNl/Z7mkTz2+AFUaf5IbYTyOMooA8Vxkh52BLunjcyjSrP7 Go6cU0i69YTLLGVe814Pg== X-UI-Out-Filterresults: notjunk:1;V01:K0:EMsyY6uPLRg=:EScDJm6/xG77Nl0KgXwvlc PFrs1FCHuatf8MpybqHp9k2meQr94X7rB+4ncyL+PSPttXtNr4MhN8ROufdwZQ4bHVy6ItDKD jYnosilIt0mti4lB9Q91EQmNfNuVWPYDlq7iP+3bqTvmyuev+kAtNmFNRdlyHX1lg54x4aKvQ 96VLDdaEdScZ2zlGNYvd68oO749bXAZ1Fno/NtMeKmM4nNnybChoDLrhDPs0/Tzws7QkHG73b yROex0g10Ba6HekcL7e3qRVfI6zAEzJwR0KwrUPRamrqtjlKZV5pRPU/FYtaLlM1ejvxmVBZk 9Xo52j2+bi6AXq3E50rbTqx3GxTlktIlGxXVG46CoQy2ncKDnamHIajRdMUIshBvL71CNBnDd gyq6mU61SP3WnjKGgEzEGZkgoFXJTf6Ebh9SpGwCTm6ybOxnU1T6yD0EHBA5yKMgRby39UOZd hO1ekF71LEcMlDyt1d0VRwezr+EZ0WEg2keaA+gViqLVlyBgIaKxGqswbV9ZoQF/vWcPblsNd JIYJm9/ioObxQZvPqcFqOeJGcbyTVEfLRN0uzPddrG8GFoYQCmv7vMAZFgUERV5D9L5YH1nYS f5Xlos6cRi73g2h/KtZqFIQHuvPy/HsBje5l8EqCyuhGMWd3+GfYA1YGtbQsfUqSTTMrD3+g+ D/Cosa5wdnCpqaZMeRoKQ4ObWBqNldaFbF7P2TsWBeUDCXywYaS1aqGtqU48wGfs0GJQA3a9m wfhmRHwN2qYt209kMAVzGoGtdL+farMeh685RO9l7N+1MXC4vPfMYXL+oelKHupQ7jC1+SlH7 KRp3oUb X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 32502 Cc: gazally@runbox.com, 32502@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: >> From: Michael Albinus >> Cc: gazally@runbox.com, 32502@debbugs.gnu.org >> Date: Sat, 25 Aug 2018 12:53:02 +0200 >> >> > Michael, unless I'm missing something, it sounds like Tramp signals >> > the main thread in this scenario. (current_thread->error_symbol is >> > only set by thread-signal.) Is that really necessary? If so, can you >> > describe why you needed to signal the main thread, while it was >> > waiting for input? >> >> Tramp propagates all signals to the main thread, otherwise they are not >> visible. > > Is that wise? It means that if a user is doing something in the main > thread while the Tramp threads run asynchronously, the user's program > will/might error out. Perhaps not. But I didn't like that no Tramp error was visible from a thread. >> However, if we apply this I don't know how to quit (let's say) 250 >> threads. One quit signal is good for one thread only. I believe we need >> also a mechanism to quit many threads at once. > > I think we should simply make thread-signal a no-op when it signals > the main thread during the time the main thread is waiting for input. Perhaps. But I don't understand how this solves the problem (quitting several threads at once). Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 25 12:07:58 2018 Received: (at 32502) by debbugs.gnu.org; 25 Aug 2018 16:07:58 +0000 Received: from localhost ([127.0.0.1]:60728 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ftb6U-0005m1-Dz for submit@debbugs.gnu.org; Sat, 25 Aug 2018 12:07:58 -0400 Received: from eggs.gnu.org ([208.118.235.92]:52908) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ftb6T-0005lp-2c for 32502@debbugs.gnu.org; Sat, 25 Aug 2018 12:07:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ftb6K-0005tO-Px for 32502@debbugs.gnu.org; Sat, 25 Aug 2018 12:07:51 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48903) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ftb6K-0005tB-MP; Sat, 25 Aug 2018 12:07:48 -0400 Received: from [176.228.60.248] (port=1259 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ftb6K-0002w6-9x; Sat, 25 Aug 2018 12:07:48 -0400 Date: Sat, 25 Aug 2018 19:07:37 +0300 Message-Id: <83muta77li.fsf@gnu.org> From: Eli Zaretskii To: Michael Albinus In-reply-to: <8736v2bfzx.fsf@gmx.de> (message from Michael Albinus on Sat, 25 Aug 2018 17:52:34 +0200) Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> <83pny67h2y.fsf@gnu.org> <8736v2bfzx.fsf@gmx.de> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 32502 Cc: gazally@runbox.com, 32502@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: Michael Albinus > Cc: gazally@runbox.com, 32502@debbugs.gnu.org > Date: Sat, 25 Aug 2018 17:52:34 +0200 > > > I think we should simply make thread-signal a no-op when it signals > > the main thread during the time the main thread is waiting for input. > > Perhaps. But I don't understand how this solves the problem (quitting > several threads at once). Well, you never want to end the main thread, do you? But perhaps I don't understand well enough the situation you are talking about. Can you describe in more detail when and why do you need to "quit several threads at once"? From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 25 17:53:34 2018 Received: (at 32502) by debbugs.gnu.org; 25 Aug 2018 21:53:35 +0000 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 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==; 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 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 From: Gemini Lasswell To: Michael Albinus Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> Date: Sat, 25 Aug 2018 14:53:24 -0700 In-Reply-To: <87o9dqbtv5.fsf@gmx.de> (Michael Albinus's message of "Sat, 25 Aug 2018 12:53:02 +0200") Message-ID: <87efemp0yz.fsf@runbox.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 32502 Cc: 32502@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 26 09:51:07 2018 Received: (at 32502) by debbugs.gnu.org; 26 Aug 2018 13:51:07 +0000 Received: from localhost ([127.0.0.1]:60973 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ftvRb-0007p8-2s for submit@debbugs.gnu.org; Sun, 26 Aug 2018 09:51:07 -0400 Received: from aibo.runbox.com ([91.220.196.211]:36902) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ftvRX-0007oz-UC for 32502@debbugs.gnu.org; Sun, 26 Aug 2018 09:51:04 -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=qu9vFaJmPZaTpSAE/lthpD5uPwTj7Db1P5jI24yCAjU=; b=ey6w/I9daLPF7TJqYy5McYp3ih 8bv93aOpMb0B6Ns2y2p4QEzKAmFeMf/TBIngn5z7St7o7IUqIcwH9+s7dzGNhx4ny0tyC6u22erVY VCxYNNH2C3S7Mt+pKuWI3llXB6qcNoFVleZkuz7GuauGRD0TjzlQex0/X2Wf9F0OkEOlEVaQ/bxgy zAkH0ED1Ma7+Zjrm/WxJzoGSElvSAgijJ/DFl2lK7ISB0Sw2UMWQ0ktf3HqMenLFWsaOjnG0Wtj1n P5I9Ngb0WoUAPsiveHuNwwnAmIpPi1BWKJNrRY/vJj+MUQxvMl3QTSa+j2Q87BAKH0L1BwhE2mVXF hmVlmxnw==; Received: from [10.9.9.212] (helo=mailfront12.runbox.com) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1ftvRW-0002Py-5d; Sun, 26 Aug 2018 15:51:02 +0200 Received: by mailfront12.runbox.com with esmtpsa (uid:179284 ) (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) id 1ftvRJ-0000ZG-Ki; Sun, 26 Aug 2018 15:50:50 +0200 From: Gemini Lasswell To: Eli Zaretskii Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> <83pny67h2y.fsf@gnu.org> <8736v2bfzx.fsf@gmx.de> <83muta77li.fsf@gnu.org> Date: Sun, 26 Aug 2018 06:50:47 -0700 In-Reply-To: <83muta77li.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 25 Aug 2018 19:07:37 +0300") Message-ID: <87a7p9p77s.fsf@runbox.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 32502 Cc: 32502@debbugs.gnu.org, Michael Albinus X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: > > Well, you never want to end the main thread, do you? > > But perhaps I don't understand well enough the situation you are > talking about. Can you describe in more detail when and why do you > need to "quit several threads at once"? The ability to quit multiple threads at once also seems useful to me. One possibility would be if you do something like this, to open up all your project files at once: C-x & C-x f /scp:server:project/worktree_a/*.el RET And then after you press RET, realize that you meant to type worktree_b instead. Or after you press RET, realize that your network connection is too slow for what you've asked Emacs to do, making you decide you'd like it to give up. Or each of the threads starts reporting the same error, and you realize none of them are going to work, and you want to make the error spam stop so you can fix the problem. Right now the "Checking vc-registered" phase of multi-threaded find-file hogs the global lock and makes Emacs unusable for a while if you are loading many files at once; maybe that, or some other package in your config which wasn't written with threading in mind and gets called by your find-file threads, makes Emacs slow and goes on for too long, and you want to make it stop so you can do something else. C-g is probably not the solution to these situations and I'm not sure what is, but it would be nice to have some way to resolve them besides restarting Emacs. From debbugs-submit-bounces@debbugs.gnu.org Sun Aug 26 10:13:02 2018 Received: (at 32502) by debbugs.gnu.org; 26 Aug 2018 14:13:02 +0000 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 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 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 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 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 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 Date: Sun, 26 Aug 2018 17:12:42 +0300 Message-Id: <8336v16wth.fsf@gnu.org> From: Eli Zaretskii To: Gemini Lasswell In-reply-to: <87efemp0yz.fsf@runbox.com> (message from Gemini Lasswell on Sat, 25 Aug 2018 14:53:24 -0700) Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> <87efemp0yz.fsf@runbox.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 32502 Cc: 32502@debbugs.gnu.org, michael.albinus@gmx.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > 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. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 29 12:01:14 2018 Received: (at 32502) by debbugs.gnu.org; 29 Aug 2018 16:01:14 +0000 Received: from localhost ([127.0.0.1]:37304 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fv2uA-0000F7-2s for submit@debbugs.gnu.org; Wed, 29 Aug 2018 12:01:14 -0400 Received: from mout.gmx.net ([212.227.17.21]:56641) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fv2u8-0000Eu-D8 for 32502@debbugs.gnu.org; Wed, 29 Aug 2018 12:01:13 -0400 Received: from detlef.gmx.de ([79.140.117.4]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MV1wf-1gRDIA1GLl-00YPbB; Wed, 29 Aug 2018 18:01:03 +0200 From: Michael Albinus To: Gemini Lasswell Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> <87efemp0yz.fsf@runbox.com> Date: Wed, 29 Aug 2018 18:01:02 +0200 In-Reply-To: <87efemp0yz.fsf@runbox.com> (Gemini Lasswell's message of "Sat, 25 Aug 2018 14:53:24 -0700") Message-ID: <87pny1xiv5.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:8BzlifjLTx3sopXMSwhL5oKyTyS8EIqo9xswZou9WfMXADmWtcf 5p39AIGoAkzs1uIDJTIRZu76fWcmyy4j9Ts2xk6K9MklBpq8pPeSdFYB4+mP6xzjIfx5pGJ ojtTCjz0BBTK4bk1CeIBX3++Kyckn+1stmM+A/NIyvtqSl2Ptgtz+ew4uH7hQK1Rd5umZox C/lD/0f/pfBjhc3OMwDlg== X-UI-Out-Filterresults: notjunk:1;V01:K0:SO3G4r1SCEs=:hNAPmVTWqQWwdnF1n2QwN0 3BNucNQMGy+5P8QlolKp/hixYxuDEvEQli18IzJCRWOAmegFNd/E2QH8zCP8YkKRGR5c+oMFz WM/XEfOcKAuvNGNE0dFozCnWCpeooGxG1XmZc1TRVMRn7IGjhDrqeZJLUoK4G5M3p6tPv+6+Z mxsg8qBUnAnDwvfRx3tzyVz/DahoTkQq75ts1xI8gfXP1uX0mPIdJq2nq92809zy6skqXfRCV EnPkmahDROuQuBEQCOm6tBRR7XW7Wjjv9B9W7GNrxZ+Oh/v00qECANOK6U1N4mfYhBSBsOvy7 1IeQ95htMpssF5qaUJY1S0I7YK1M8AZFHrgMUIF4z9Q2VtrrpyXX8W3n0C47/HsDLx8TBTwJC EBOgdn+Rj1CYON+WkqAkkFBSVIgSYz/3LmrL3F1CNo3q9seuUnjYs2waMCuDLIYPDj3PKHDU6 ZSmfxtuKK8BGDlC1V4lknOaiQSloBgY0PoHyQAI3XCLq0Adhqi+9cbp86rnbZTOKZtjnlHscI kZAX5t9/Cm1uetFzL3KSD6mtXKCCpZlu2CY0T6cqnH1TJrkjeqbEDUaU0E6cdYMMGbDWs5+Zm UYk8P8NevLaIabFzKtgsmkfkU+YzLN4ft5SK/VQBCS/zo6XfhEi+JB2E2K+4zJQ1Kdc3dfbZY 1cXKgo6lAq+v3SMTNA5D8yM1s4zYXrnEZS9YXvx/a3RNPVgzMjfwrl6k7uyIpZHnZj2vw2nku W0jX5HqJ2GWSQ7bAeYMwl4Qf7A/XmzASH/z7jJu2wr2nGZZuEK1lsVZ/2C6/S7rG8vjyf4TQL pdtulIa X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 32502 Cc: 32502@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Gemini Lasswell writes: > Hello Michael, Hi Gemini, >> 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. For me, Emacs aborts even w/o any user action. Just waiting. > Emacs aborting in this case is arguably by design, not a bug. Why do you believe that aborting is by design? I would regard it as a bug. Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 29 12:23:22 2018 Received: (at 32502) by debbugs.gnu.org; 29 Aug 2018 16:23:22 +0000 Received: from localhost ([127.0.0.1]:37315 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fv3Fa-0000li-6H for submit@debbugs.gnu.org; Wed, 29 Aug 2018 12:23:22 -0400 Received: from eggs.gnu.org ([208.118.235.92]:45681) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fv3FX-0000lS-Df for 32502@debbugs.gnu.org; Wed, 29 Aug 2018 12:23:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fv3FP-0003Il-4j for 32502@debbugs.gnu.org; Wed, 29 Aug 2018 12:23:14 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51767) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fv3FO-0003IN-Tl; Wed, 29 Aug 2018 12:23:10 -0400 Received: from [176.228.60.248] (port=2287 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fv3FO-00023w-Fs; Wed, 29 Aug 2018 12:23:10 -0400 Date: Wed, 29 Aug 2018 19:23:06 +0300 Message-Id: <83in3t2lcl.fsf@gnu.org> From: Eli Zaretskii To: Michael Albinus In-reply-to: <87pny1xiv5.fsf@gmx.de> (message from Michael Albinus on Wed, 29 Aug 2018 18:01:02 +0200) Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> <87efemp0yz.fsf@runbox.com> <87pny1xiv5.fsf@gmx.de> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 32502 Cc: gazally@runbox.com, 32502@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: Michael Albinus > Cc: Eli Zaretskii , 32502@debbugs.gnu.org > Date: Wed, 29 Aug 2018 18:01:02 +0200 > > > Emacs aborting in this case is arguably by design, not a bug. > > Why do you believe that aborting is by design? I would regard it as a bug. Because the code speaks for itself: static Lisp_Object signal_or_quit (Lisp_Object error_symbol, Lisp_Object data, bool keyboard_quit) { [...] if (gc_in_progress || waiting_for_input) <<<<<<<<<<<<<<<<<<<<<<<< emacs_abort (); It could be that the reason for that is no longer valid when the signal was raised by another thread, via thread-signal. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 29 12:46:15 2018 Received: (at 32502) by debbugs.gnu.org; 29 Aug 2018 16:46:15 +0000 Received: from localhost ([127.0.0.1]:37327 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fv3bi-0001Jt-RK for submit@debbugs.gnu.org; Wed, 29 Aug 2018 12:46:15 -0400 Received: from mout.gmx.net ([212.227.15.19]:58325) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fv3bg-0001Je-Pp for 32502@debbugs.gnu.org; Wed, 29 Aug 2018 12:46:13 -0400 Received: from detlef.gmx.de ([79.140.117.4]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MVvi4-1gS1rv1Sjg-00X18o; Wed, 29 Aug 2018 18:46:03 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> <87efemp0yz.fsf@runbox.com> <87pny1xiv5.fsf@gmx.de> <83in3t2lcl.fsf@gnu.org> Date: Wed, 29 Aug 2018 18:46:01 +0200 In-Reply-To: <83in3t2lcl.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 29 Aug 2018 19:23:06 +0300") Message-ID: <87lg8pxgs6.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:70CtIjIZ0ilzxGUKm6JvvplxkLpYMf7b3KFDg+MmFydFImp7w+b hpO/ZvQ6DG0QEow1IkqukTpsDDOfNS5cAg8K83XA4nHBlBXhkndyUYy9A2tjayabxAiK8vL MhtEC1gKYDW/5jaKiZgFTmJrZU9j8nUf+IdTsDmwoC3914gMMeD4MDFMxRnxX6VS1na7Nfr coWs91wAAetb+M0KryjBg== X-UI-Out-Filterresults: notjunk:1;V01:K0:ZOJIKIq2Iog=:mmB9qMTmMQC0N2dT8N0fJM m/crwF+itKtGGc4F2X5tGjQq30F1nTkOz+mbxGQMUguMyOcdwLLme6qLOFRL3/ow7OngtobU+ YvPI2/6WMzsw01wGH3XQxLcyNNAdlRRW9HdvJ1HSnT2+WbtMHPBUNcwyQcst0VGAMrKK+2fBR Ikdu6A6+xKufYCh/N3Vq6v10jJVo3gxkG8oCO2MJV/AK+UbZtRi5xRLTD4VNhWqGBJPYrPgly ep+0xkCLGhglbUPdwhVSc86eANZa3V6agYiEw467fsJrg3wy9Slqc6fcr/F/n75w5NmWKTX5V aNEU+6QWpsT7NoRjL7Ro8yGYcAykQZMYMj43t3uElSGb0YN3MolOl1KlQtSzaicfGexhmhTWy lVnx/4VOjyaylPvPkjVPNDgk8VAzRLPXXqqgpocoFhUn9dnbGf2D8RuNdHEHiLrv5YGxr4tdd 63S2XIy4XXi4jQuc2SfDx2fcHd+kNm5JIiXz87MBTsC3qwfM4a4B5ZhVaxcZneJyH3sJYt6TX aWtN8dDjGZR3ozolyKrwPIvW1ObEFsmgApzHdSYt0wDOO1UIEqRAizUgnwH4QMPmbGtmaZ+Cf WG9qxQ01sF5ZRVbLTdo1ZREdACoiiY8O7XQVHbtidAw4qtM4oAMlwUX+UH0tP6e8Nrc/GVFl5 GsM5MikKNBIPDIOAzAEkh/Wrd+UQD64BIIN1EMCjwTkZbJWIEz2TLtIbe0ZYa+JdwLTYaEyU4 rSPboYLG7Ae+bYGXBWao6PgRr24MOcngruRa5k/sQaPnP8XAOIh67OIaf5mKE3IU8MJ/+oPjU viCyRYW X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 32502 Cc: gazally@runbox.com, 32502@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: >> > Emacs aborting in this case is arguably by design, not a bug. >> >> Why do you believe that aborting is by design? I would regard it as a bug. > > Because the code speaks for itself: > > static Lisp_Object > signal_or_quit (Lisp_Object error_symbol, Lisp_Object data, bool keyboard_quit) > { > [...] > if (gc_in_progress || waiting_for_input) <<<<<<<<<<<<<<<<<<<<<<<< > emacs_abort (); > > It could be that the reason for that is no longer valid when the > signal was raised by another thread, via thread-signal. But I haven't done any user input. I've evaluated the code snippet given by Gemini, and then I've done nothing. Emacs was idle I believe. And it aborted. I will bisect, in order to see where this bug comes from. Best regards, Michael? From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 29 13:03:51 2018 Received: (at 32502) by debbugs.gnu.org; 29 Aug 2018 17:03:52 +0000 Received: from localhost ([127.0.0.1]:37343 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fv3sl-0001kk-KE for submit@debbugs.gnu.org; Wed, 29 Aug 2018 13:03:51 -0400 Received: from eggs.gnu.org ([208.118.235.92]:59023) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fv3si-0001kW-4Y for 32502@debbugs.gnu.org; Wed, 29 Aug 2018 13:03:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fv3sZ-0006JG-P9 for 32502@debbugs.gnu.org; Wed, 29 Aug 2018 13:03:42 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:52711) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fv3sZ-0006J6-JI; Wed, 29 Aug 2018 13:03:39 -0400 Received: from [176.228.60.248] (port=4842 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fv3sZ-0003T6-6C; Wed, 29 Aug 2018 13:03:39 -0400 Date: Wed, 29 Aug 2018 20:03:33 +0300 Message-Id: <83h8jd2jh6.fsf@gnu.org> From: Eli Zaretskii To: Michael Albinus In-reply-to: <87lg8pxgs6.fsf@gmx.de> (message from Michael Albinus on Wed, 29 Aug 2018 18:46:01 +0200) Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> <87efemp0yz.fsf@runbox.com> <87pny1xiv5.fsf@gmx.de> <83in3t2lcl.fsf@gnu.org> <87lg8pxgs6.fsf@gmx.de> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 32502 Cc: gazally@runbox.com, 32502@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: Michael Albinus > Cc: gazally@runbox.com, 32502@debbugs.gnu.org > Date: Wed, 29 Aug 2018 18:46:01 +0200 > > > static Lisp_Object > > signal_or_quit (Lisp_Object error_symbol, Lisp_Object data, bool keyboard_quit) > > { > > [...] > > if (gc_in_progress || waiting_for_input) <<<<<<<<<<<<<<<<<<<<<<<< > > emacs_abort (); > > > > It could be that the reason for that is no longer valid when the > > signal was raised by another thread, via thread-signal. > > But I haven't done any user input. I've evaluated the code snippet given > by Gemini, and then I've done nothing. Emacs was idle I believe. And it > aborted. That's just it, AFAIR: when Emacs is idle, the waiting_for_input flag is set. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 29 13:15:59 2018 Received: (at 32502) by debbugs.gnu.org; 29 Aug 2018 17:15:59 +0000 Received: from localhost ([127.0.0.1]:37353 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fv44V-00022B-4B for submit@debbugs.gnu.org; Wed, 29 Aug 2018 13:15:59 -0400 Received: from mout.gmx.net ([212.227.17.20]:60303) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fv44T-00021x-S9 for 32502@debbugs.gnu.org; Wed, 29 Aug 2018 13:15:58 -0400 Received: from detlef.gmx.de ([79.140.117.4]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M09Ee-1feMZ73jLQ-00uEvy; Wed, 29 Aug 2018 19:15:50 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> <87efemp0yz.fsf@runbox.com> <87pny1xiv5.fsf@gmx.de> <83in3t2lcl.fsf@gnu.org> <87lg8pxgs6.fsf@gmx.de> <83h8jd2jh6.fsf@gnu.org> Date: Wed, 29 Aug 2018 19:15:47 +0200 In-Reply-To: <83h8jd2jh6.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 29 Aug 2018 20:03:33 +0300") Message-ID: <87d0u1xfek.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:g+7tFdhX2u3Zqpc9LgfazjDxn3lk2idnzsdaw4Kzao0anMjdZHG lnJD+m0gTrkXZcls2HU/+xpE+HMXSwYNRn8mynXDw8F3369mCMPJDcx3GLxf1hOKhTNzbRH 1XO8NNX7eJ5t7RRhZX+UQcMX7PGffSWkOGBAm1wWlYhYDMF7DtW2D8e+X8Jkv1lrSQ5ywm+ /0NYvan/aoZSyXziVN43g== X-UI-Out-Filterresults: notjunk:1;V01:K0:+aJgLNFirkI=:DlwDkj2OAZ5Vn7KW57FiEk XuDLMPMgw8BeSDTfjn+d8I4aRP7n6wT7iYJF9i3GJwT+1Hq4KY6Pz3c3hcR9UFHEkFbMIFMrP wH/yB0aV4kGXNfsSpXeRl8f3NQgia7egGoCo4gHkMsbwED2MK2bUzmSv69JEldpWfg4R+3W+8 yhFlskzOhlOXKv8cK/MWh5G+oKpe7+AGjwWrLDlSBkeBvUn5QaotM9sck6pCbLfNnW3L2NmMN t6LCm01fTg/8bKZ2Pc1bzRUOc6zgh+ctI+XnF6B/EhaZSdLUsB5dO3lHDT4/9RuzQazxPmyXJ CMQ5yyWH8YNMZCuz/4PWkbg6vqDCGD+zCJuEL1fegK0mXa12j/V/0hdcjjVdNoDt3ahy5dQPM fYTYXChbpORE4c7h/7WVsmMivhE3n2CSkQCPJA6K0dSxlAAEdGjkrMF6RK+VdoD211nuXbkTy YeIDymuSp7yVRVp+PT2EM5av8SBn3rk8tBzRXf5A9zVHae7Ug+tmWgidvqHZOJ9E6IoPdiaVN UzKpBN4/qQcNKC8Msn1gqCxNfjhhc8VhlrBorCxhgzozdiv2XP+qWz8YHs5aTTsCbimLQ8FfV +RtF8M/jyYY5SJQ7d31Tt/XYWfotH9tQWcOjRif43owadqP4AZQNsE6ov7g10M/20dqd+RX5h nf/JCpBS+cNEBBjUO8M9i8zDvhg66v997T2BEoSqaPcpsDaqG+bFyorMRO47kgKvB09CZaIDI FVNjTDd/GxrXXmOv9MXNq5ZnXkZ6CPq3bNcPq1y2sNTYEfgYxO+yYsp5xsZ0hVKCIAAJYr7En aViHa0u X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 32502 Cc: gazally@runbox.com, 32502@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> But I haven't done any user input. I've evaluated the code snippet given >> by Gemini, and then I've done nothing. Emacs was idle I believe. And it >> aborted. > > That's just it, AFAIR: when Emacs is idle, the waiting_for_input flag > is set. In this case, you cannot send a signal to the main thread ever. That contradicts the documentation in (info "(elisp) Basic Thread Functions") --8<---------------cut here---------------start------------->8--- Since signal handlers in Emacs are located in the main thread, a signal must be propagated there in order to become visible. The second =E2=80=98signal=E2=80=99 call let the thread die: (thread-signal main-thread 'error data) (signal 'error data) --8<---------------cut here---------------end--------------->8--- Let's see, what the bisecting tells us. Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 29 16:22:17 2018 Received: (at 32502) by debbugs.gnu.org; 29 Aug 2018 20:22:17 +0000 Received: from localhost ([127.0.0.1]:37459 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fv6yn-000252-BY for submit@debbugs.gnu.org; Wed, 29 Aug 2018 16:22:17 -0400 Received: from mout.gmx.net ([212.227.15.18]:58923) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fv6yl-00024o-Hq for 32502@debbugs.gnu.org; Wed, 29 Aug 2018 16:22:16 -0400 Received: from detlef.gmx.de ([79.140.117.4]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LwaQZ-1frGEb1Wxz-018HId; Wed, 29 Aug 2018 22:22:06 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> <87efemp0yz.fsf@runbox.com> <87pny1xiv5.fsf@gmx.de> <83in3t2lcl.fsf@gnu.org> <87lg8pxgs6.fsf@gmx.de> <83h8jd2jh6.fsf@gnu.org> <87d0u1xfek.fsf@gmx.de> Date: Wed, 29 Aug 2018 22:22:04 +0200 In-Reply-To: <87d0u1xfek.fsf@gmx.de> (Michael Albinus's message of "Wed, 29 Aug 2018 19:15:47 +0200") Message-ID: <878t4oylcj.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:sDToAnMECQwHVaUwjfB+kMGXTx2UHQN9r9pHIziKLkdCe8CPpK4 WQ9yfjPPtd7t8HW3LOoF+6XRjFN3+doK40ucwqjJRS6wMS+gl8cFxuQj6m4yYpv0ANPpsmT BI0Q7L8vhi/XqgpWep3yTjDxPUkbgWvpsiUQk8g+wnYD/4ZZn+xDrnrgnupFq1nyDlqXDug WGgUU5QZovH0W9fyhmlsQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:x8YBzrChxe4=:Xngk5k0bOUN1dTza9x7tHz kEB5w6CrQ9NxUEkfFMJNbaHTBpWEP1fdS38GAiqRabVmgIZ2hLvQcHMLszKbMTdt56ylYRcwG eivOrQZhM3LcfN4i9WonI/f3IvcXVru0LK/kQvqqLwEwytoBGZwe8pZ6aRxctFalOdtVUeVzK sMys0VpOSCixjZSPEoodAR2Q4yKUv7LpeLgplfBcyrALTRDFtrEebgBvsY/KSZPu8AHIpuLGa pazPgpRYJw72aYpNKJoRhf9eIUSB6B91ltgdYwW4vlUBnCyJJrYekN1n7V+PNtF8YSqc5bwyL a8wUvIj61e2qH5o4BjZU7M9j0UaddF1K7UVFLBxcwNul560/HbMyQcZAhGlwFkUKtgJ0JeS9f 2RqpFZmfjSGsyB1neZ3AcdpaxdhJ1lAqEdy3O4rvC8Wd0EwlAaw9nyKz2lRTQF1g88VJFUGqD z49vxreM/38JCPIgdjVxBFch4KWhdWFxWKio+rI1DRzDmbTb7+vFaZdIggiM5VhymfQ1pJTty Q8a7jB+2BhuXvVKyzkeqfqM3m9mCYt1nJ3GSAyDi/tti6bPfy4ZZaUr1oVNDM2xanVWFgrL9R zXoEySjj6UEPx7b1Iv/f59NyKbivYd8dF2U1Juo9SP4dMY5Y63Wq0rJLPe55PS5/iWiyUQ4p5 BOlmJV4eSUbUWerts+jp2GH7hEs8l4Bf/SPR/SpK1MQJodDFuCmbay2AbFWrvE1uzjxuHADRL sDHkDvs5bU3fsqHtRJFSxGfEtlfaRQ6jtIOX6KXnJlm/vCY0n0mHP7Oiwj3bm7OdkXB52P0XS DEskyEQ X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 32502 Cc: gazally@runbox.com, 32502@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Michael Albinus writes: > Eli Zaretskii writes: > >>> But I haven't done any user input. I've evaluated the code snippet given >>> by Gemini, and then I've done nothing. Emacs was idle I believe. And it >>> aborted. >> >> That's just it, AFAIR: when Emacs is idle, the waiting_for_input flag >> is set. > > Let's see, what the bisecting tells us. Emacs started to abort with the shown example with commit 798cbac170. Well, this commit is from me ... Will continue tomorrow understanding what's up. Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 29 16:57:39 2018 Received: (at 32502) by debbugs.gnu.org; 29 Aug 2018 20:57:39 +0000 Received: from localhost ([127.0.0.1]:37507 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fv7X0-0004xu-TI for submit@debbugs.gnu.org; Wed, 29 Aug 2018 16:57:39 -0400 Received: from mout.gmx.net ([212.227.15.15]:35811) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fv7Wz-0004xR-2f for 32502@debbugs.gnu.org; Wed, 29 Aug 2018 16:57:37 -0400 Received: from detlef.gmx.de ([79.140.117.4]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LyWAQ-1fpKnx0XIM-015uH9; Wed, 29 Aug 2018 22:57:27 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> <87efemp0yz.fsf@runbox.com> <87pny1xiv5.fsf@gmx.de> <83in3t2lcl.fsf@gnu.org> <87lg8pxgs6.fsf@gmx.de> <83h8jd2jh6.fsf@gnu.org> <87d0u1xfek.fsf@gmx.de> <878t4oylcj.fsf@gmx.de> Date: Wed, 29 Aug 2018 22:57:24 +0200 In-Reply-To: <878t4oylcj.fsf@gmx.de> (Michael Albinus's message of "Wed, 29 Aug 2018 22:22:04 +0200") Message-ID: <874lfcyjpn.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:rNMbSKltqd/qLNyFMDJobT35Mf4+3fCWAqA+CRzOtF19DGLvXvg he0JuALEoez13KqZfjQqqAGBDEwlxRTDAlC1NAcFQe+C8TYSorUVNrNCtCMi9U57MHB4QrF Y5Ad0qZFHTRk5V1xbsZ+Zg0AIhkDsLhb/d8NvM43//hE0gu3B22tKQw5eTDBzg+AOZOHspJ /7x9AunyMJ9uuSZGHM8Aw== X-UI-Out-Filterresults: notjunk:1;V01:K0:Cec5RmIza+8=:ux5B3L4viq/mgqqdK8N+H+ ITTd8sXYu+5ofJjhMtd7/GkuEhLqgu7oKiQ4G1Jhmf2JrYSiDYJO6xwaSQebvzAIBQpUbLyVV 0iAzr2M6wQTdVG17GB+u2UMn34g6fozvod37VxRmdevrFz60Mmcper2XaQG9bMdWyPnmx01Hr T7OXHY3RrfyEo6T5I9t9vE64wjZeYynloqpdLsXsxHdJt0ndZAGwgaVesjhnm8+j8smPvIXMp mzDU/IkqMUqKkXIbVdaiIkPYv5f50rMol0bgJsxb6MsgNP49lBnd4WHgWePCMbAVAxIYF/IPr sT3F6LZ+vuymKs/rLnhPR+FHQMBbnV1BnGrdxyz72gtMXtXdtidIm2ga7w8VsZdaxFgc5Vbvk Nrir0ioVwaO7+WDnhPCemWYpnv+EF44qKir7qwncZjjgDUO6+8H1+4lR9KIUkMFK1w4pB0esf 0doGzCWW7/0GObGZAMe5mw24yFiu3fBZBfQ8FxUf1cHy1lZOYmnZDjrkVfiF/B8EMg2gaRwEi JQ5o2/L+EcRUe07xhbBU2Pr1qtiO8vc0dOIMnk2Owi7w5cD3dmpyTug/cGoZh8eB584rVjLOY 0zcd+4jLUSqogj9Rx4bfKUgHLiRrxTv0oWpmfCFvAyMegwW8LSn7uXUZ5Z6Twu7txUH0i1nPx 0Jc741iK3vZxnhkwXinOfdclj16Cmzc4K3J8Ihd56EnqubtKft3WoaPE+Dzh2RUfe/GGqfMjF ovy2ntkgZK+s0poOOBE3O12WnjxXna/Sx+XXj5I2pIVa0JQlYZCoU3We/cgKvPgms30nW2O3i eZclBU5 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 32502 Cc: gazally@runbox.com, 32502@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Michael Albinus writes: > Emacs started to abort with the shown example with commit > 798cbac170. Well, this commit is from me ... This commit introduced the variable main-thread. Before, the thred-signal call couldn't deliver a signal to the main thread, Emacs couldn't abort. So it looks like you are right: we cannot send signals to the main thread. Is this acceptable? Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 29 22:36:27 2018 Received: (at 32502) by debbugs.gnu.org; 30 Aug 2018 02:36:28 +0000 Received: from localhost ([127.0.0.1]:37752 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvCot-0000TD-Ma for submit@debbugs.gnu.org; Wed, 29 Aug 2018 22:36:27 -0400 Received: from eggs.gnu.org ([208.118.235.92]:36526) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvCos-0000T2-UY for 32502@debbugs.gnu.org; Wed, 29 Aug 2018 22:36:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fvCoj-0003nz-BM for 32502@debbugs.gnu.org; Wed, 29 Aug 2018 22:36:21 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36401) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fvCoi-0003na-6w; Wed, 29 Aug 2018 22:36:17 -0400 Received: from [176.228.60.248] (port=1430 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fvCoh-0003e1-QP; Wed, 29 Aug 2018 22:36:16 -0400 Date: Thu, 30 Aug 2018 05:36:01 +0300 Message-Id: <834lfc37ji.fsf@gnu.org> From: Eli Zaretskii To: Michael Albinus In-reply-to: <874lfcyjpn.fsf@gmx.de> (message from Michael Albinus on Wed, 29 Aug 2018 22:57:24 +0200) Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> <87efemp0yz.fsf@runbox.com> <87pny1xiv5.fsf@gmx.de> <83in3t2lcl.fsf@gnu.org> <87lg8pxgs6.fsf@gmx.de> <83h8jd2jh6.fsf@gnu.org> <87d0u1xfek.fsf@gmx.de> <878t4oylcj.fsf@gmx.de> <874lfcyjpn.fsf@gmx.de> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 32502 Cc: gazally@runbox.com, 32502@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: Michael Albinus > Cc: gazally@runbox.com, 32502@debbugs.gnu.org > Date: Wed, 29 Aug 2018 22:57:24 +0200 > > This commit introduced the variable main-thread. Before, the > thred-signal call couldn't deliver a signal to the main thread, Emacs > couldn't abort. > > So it looks like you are right: we cannot send signals to the main > thread. Is this acceptable? Yes, I think so, but let's document that. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 30 03:09:54 2018 Received: (at 32502) by debbugs.gnu.org; 30 Aug 2018 07:09:54 +0000 Received: from localhost ([127.0.0.1]:37846 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvH5V-0000ui-QZ for submit@debbugs.gnu.org; Thu, 30 Aug 2018 03:09:54 -0400 Received: from mout.gmx.net ([212.227.15.18]:37727) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvH5T-0000uU-Co for 32502@debbugs.gnu.org; Thu, 30 Aug 2018 03:09:52 -0400 Received: from detlef.gmx.de ([212.91.238.173]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MfEMs-1gIy6P315u-00OptQ; Thu, 30 Aug 2018 09:09:43 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> <87efemp0yz.fsf@runbox.com> <87pny1xiv5.fsf@gmx.de> <83in3t2lcl.fsf@gnu.org> <87lg8pxgs6.fsf@gmx.de> <83h8jd2jh6.fsf@gnu.org> <87d0u1xfek.fsf@gmx.de> <878t4oylcj.fsf@gmx.de> <874lfcyjpn.fsf@gmx.de> <834lfc37ji.fsf@gnu.org> Date: Thu, 30 Aug 2018 09:09:42 +0200 In-Reply-To: <834lfc37ji.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 30 Aug 2018 05:36:01 +0300") Message-ID: <87zhx4wcsp.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:I8VpxYJBFk78ANNLoREKY13vG2kiHg1OuXd7JioZOaPTUX3kXD3 rH+uxh/r+84CR4NUSPsnMLSk/8kwFYFfbwzG4QtU/BTOyGToUGryG/t/pXha7tpKHPFNqwR spKEJLxS/uYsvwhO0AeevFcxSWnWYEXwtwKlgnQG5t1ZmhUbsEkJB6PGl6PrZggLu5MxImH 1ko4dgKdt0MTTHimLUUOA== X-UI-Out-Filterresults: notjunk:1;V01:K0:UGzVXfmGF+8=:9H8IxfEfuXtfftW30ZqK1c hYF2etH66UmhopE69vFbBVM2p2cM+gnr10ZZtGeae6UntmzXGVNfIWLa/iwLEaLVHfb1AcVye LKjnNOccmL4zZuMbvPD95VoA98JuBQkC5JwgQsnHYhn1MfpotaGhsyjcmOdlQqJkguXY0r406 okmLa13jH3Q0Pi2HsUOk6RHQ9JTa2R9yH0TpBAMpa/rzsrUU5m75WiXeSKznYhj7rsi9v584W lUUZnNpUTWJi6eGxjWo5CQ/AjLVyZVLi8DL9NGb6WxiIRC2GAXRLE5xnhKf6AvydY9qZAbcSn aFghw6w1yEhtpr6NDXXGh+P4udL+bqkq2Q0qeSKidoxyh6UmHqW0aZEMU9G0pDrpnetR7ErQd TNeGBF1va7P3ITC5G5W8Uepij8wLDuBYAlYEjjgaq4SgbxJkXBq8Miw9izOkcnKZbvpngh/98 /0u2Ir+eyC4yS7PpPF0OsL02ORv3xIpZye3keFhOe6XoK03aLt9NcC02WfZtWqlMIFyWcqY/a BrVpikPGDG/Ca9gLviwQK37i/Z8E6BzJ2VjdKDFRMl+8Fe6MbPti+qmpBzsO595wFchEXpTn5 wkfkZZgBUSyeuwUlWZPnzTA28Mf4tKK2UZ3kRwhvfsrM6CbvWBcmR435CzXiOLSSuAtzH+TD3 96mmFm6HpWxQIN22+1OoT0IUIinsDYPST4920PUTxesikq8+hurPKZgu0RciWnz671zEsRARk aq+TyfByG0ARiNHnf55+DThMvCDikVG6ZlvnPurvui5O1SSQbwF6JW5bnhyfDnZEzD9F8kc87 OWZfxZW X-Spam-Score: 4.2 (++++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii writes: >> So it looks like you are right: we cannot send signals to the main >> thread. Is this acceptable? > > Yes, I think so, but let's document that. Sounds to me like a serious restriction. When something happens in a thread, I want to know it. There isn't even a message about the error. [...] Content analysis details: (4.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (michael.albinus[at]gmx.de) -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.15.18 listed in list.dnswl.org] 2.5 RCVD_IN_SORBS_HTTP RBL: SORBS: sender is open HTTP proxy server [212.91.238.173 listed in dnsbl.sorbs.net] 2.4 RCVD_IN_SORBS_SOCKS RBL: SORBS: sender is open SOCKS proxy server X-Debbugs-Envelope-To: 32502 Cc: gazally@runbox.com, 32502@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii writes: >> So it looks like you are right: we cannot send signals to the main >> thread. Is this acceptable? > > Yes, I think so, but let's document that. Sounds to me like a serious restriction. When something happens in a thread, I want to know it. There isn't even a message about the error. [...] Content analysis details: (3.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.5 RCVD_IN_SORBS_HTTP RBL: SORBS: sender is open HTTP proxy server [212.91.238.173 listed in dnsbl.sorbs.net] 2.4 RCVD_IN_SORBS_SOCKS RBL: SORBS: sender is open SOCKS proxy server -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.15.18 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (michael.albinus[at]gmx.de) -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager Eli Zaretskii writes: >> So it looks like you are right: we cannot send signals to the main >> thread. Is this acceptable? > > Yes, I think so, but let's document that. Sounds to me like a serious restriction. When something happens in a thread, I want to know it. There isn't even a message about the error. > Thanks. Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 30 03:19:19 2018 Received: (at 32502) by debbugs.gnu.org; 30 Aug 2018 07:19:19 +0000 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 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 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 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs 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> Date: Thu, 30 Aug 2018 09:19:04 +0200 In-Reply-To: <8336v16wth.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 26 Aug 2018 17:12:42 +0300") Message-ID: <87va7swcd3.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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/8KhASsLCkuQ5AlWddCRk6QGKSogdfpto5F8dIDDG65vHWZ3aSQbk F+zhpXk X-Spam-Score: 4.2 (++++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: 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. [...] Content analysis details: (4.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.5 RCVD_IN_SORBS_HTTP RBL: SORBS: sender is open HTTP proxy server [212.91.238.173 listed in dnsbl.sorbs.net] 2.4 RCVD_IN_SORBS_SOCKS RBL: SORBS: sender is open SOCKS proxy server -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (michael.albinus[at]gmx.de) -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.17.21 listed in list.dnswl.org] X-Debbugs-Envelope-To: 32502 Cc: Gemini Lasswell , 32502@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: 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. [...] Content analysis details: (3.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.5 RCVD_IN_SORBS_HTTP RBL: SORBS: sender is open HTTP proxy server [212.91.238.173 listed in dnsbl.sorbs.net] 2.4 RCVD_IN_SORBS_SOCKS RBL: SORBS: sender is open SOCKS proxy server -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.17.21 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (michael.albinus[at]gmx.de) -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 30 05:24:15 2018 Received: (at 32502) by debbugs.gnu.org; 30 Aug 2018 09:24:15 +0000 Received: from localhost ([127.0.0.1]:37904 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvJBW-00048E-Uk for submit@debbugs.gnu.org; Thu, 30 Aug 2018 05:24:15 -0400 Received: from mout.gmx.net ([212.227.17.22]:39757) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvJBU-000480-Aa for 32502@debbugs.gnu.org; Thu, 30 Aug 2018 05:24:13 -0400 Received: from detlef.gmx.de ([212.91.238.173]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0McEDD-1gB2mb3Wel-00JXIb; Thu, 30 Aug 2018 11:24:03 +0200 From: Michael Albinus To: Gemini Lasswell Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> <83pny67h2y.fsf@gnu.org> <8736v2bfzx.fsf@gmx.de> <83muta77li.fsf@gnu.org> <87a7p9p77s.fsf@runbox.com> Date: Thu, 30 Aug 2018 11:24:00 +0200 In-Reply-To: <87a7p9p77s.fsf@runbox.com> (Gemini Lasswell's message of "Sun, 26 Aug 2018 06:50:47 -0700") Message-ID: <87r2igw6kv.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:bss+gz8vjw67OhLe+DGdKHncDCdHAfjAcLUacburu7a4grHSvBP c08oHzow+eO+iRFFRpl0NDDcNm1GixTtBBHwD2lifZ/NUILB1Dm4XUsnAJ9g9qtpPAejKvv WJ+LfIIySqbLAmjKBs0SiNGVkbwxM550KPdbk1ZEGQ1tgd3AKwpr/3Dmi7AM7DZ6zFh9nBl gN0yyUogyD9KA62xGnbAQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:Nlg/GjIk0WY=:LeOly5FEoADuSUxMFp66+x Y5ou40tebG/Tl3MkYq/VDJCki7oFrlZfHCFDjzGc/6ktdXxmIXp4S9LDQHPGeywEo9yaT22wc 0OFA50bO6wxQjCKDshG8zxEt/zrDibrB9WQkxu5u0pN5BNroirMxsCWDrkTVfv9n/fPXxRIlf 4BxukfOLCQQ2uSoh35Yc9sZQQDWklDCFmZILD/4ockrTHXyI/A/2xYlqjHQjlH4HISbG9TXMg 5DmLp5vBCQnpX3c7eVxzCcUsGM1tNukFnHu+c4ZA8pzBHEKE6Ngs2Ga8Z72U+xfsbz8koJ8rt jcshapO+bQn9FW0G1uIAqxiH1upOHKZjPCWvpihNFnIus7M70u74RbNI9SC2ZAQPw6S1WA600 TxlCRLlErVK6VVTguRlxxYChy74otCl+1guAKRfEmFqmXD8buQGvO2zAFHZEyPqrRzZG6bwBm NH/dbubKkI2qRZvRbgU91ijyNxwI3uP3ElYpx2CQu7+z2dRwhv8CVh3KZafx6dkoKOKJXtiuY 36dSW/+NC8PmnYH8IO4qGt08xk9P7ZDKoZypnjEmtUUGlYu8DmpI7UuXD25y+ArKuSxUmVkE+ 2c2xJTlluU1myiFCn+bJUf20PTIAXhLr4YoeBH1wviB3jWlYgB7qjh8W3ZDEuAggHQfMW6lNE gpYEOTI5W4XgEaCLQExRk45AcTZV0SHwB4hYuOlegPyX5onFZqWk4QUBiSkBaSW30tXg8/Ya0 d7LGEqTGeTsu55aJgNwTGX1kqIKr9/WMN1DLQRbNlKjlOlNWlfrRQ1Xc2agmIxt3iqrT25NHB TBYYQ6l X-Spam-Score: 4.2 (++++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Gemini Lasswell writes: Hi Gemini, > The ability to quit multiple threads at once also seems useful to me. > > One possibility would be if you do something like this, to open up all > your project files at once: > > C-x & C-x f /scp:server:project/worktree_a/*.el RET > > And then after you press RET, realize that you meant to type worktree_b > instead. > > Or after you press RET, realize that your network connection is too slow > for what you've asked Emacs to do, making you decide you'd like it to > give up. > > Or each of the threads starts reporting the same error, and you realize > none of them are going to work, and you want to make the error spam stop > so you can fix the problem. > > Right now the "Checking vc-registered" phase of multi-threaded > find-file hogs the global lock and makes Emacs unusable for a while if > you are loading many files at once; maybe that, or some other package in > your config which wasn't written with threading in mind and gets called > by your find-file threads, makes Emacs slow and goes on for too long, > and you want to make it stop so you can do something else. > > C-g is probably not the solution to these situations and I'm not sure > what is, but it would be nice to have some way to resolve them besides > restarting Emacs. [...] Content analysis details: (4.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.17.22 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (michael.albinus[at]gmx.de) 2.5 RCVD_IN_SORBS_HTTP RBL: SORBS: sender is open HTTP proxy server [212.91.238.173 listed in dnsbl.sorbs.net] 2.4 RCVD_IN_SORBS_SOCKS RBL: SORBS: sender is open SOCKS proxy server X-Debbugs-Envelope-To: 32502 Cc: 32502@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Gemini Lasswell writes: Hi Gemini, > The ability to quit multiple threads at once also seems useful to me. > > One possibility would be if you do something like this, to open up all > your project files at once: > > C-x & C-x f /scp:server:project/worktree_a/*.el RET > > And then after you press RET, realize that you meant to type worktree_b > instead. > > Or after you press RET, realize that your network connection is too slow > for what you've asked Emacs to do, making you decide you'd like it to > give up. > > Or each of the threads starts reporting the same error, and you realize > none of them are going to work, and you want to make the error spam stop > so you can fix the problem. > > Right now the "Checking vc-registered" phase of multi-threaded > find-file hogs the global lock and makes Emacs unusable for a while if > you are loading many files at once; maybe that, or some other package in > your config which wasn't written with threading in mind and gets called > by your find-file threads, makes Emacs slow and goes on for too long, > and you want to make it stop so you can do something else. > > C-g is probably not the solution to these situations and I'm not sure > what is, but it would be nice to have some way to resolve them besides > restarting Emacs. [...] Content analysis details: (3.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.5 RCVD_IN_SORBS_HTTP RBL: SORBS: sender is open HTTP proxy server [212.91.238.173 listed in dnsbl.sorbs.net] 2.4 RCVD_IN_SORBS_SOCKS RBL: SORBS: sender is open SOCKS proxy server -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.17.22 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (michael.albinus[at]gmx.de) -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager Gemini Lasswell writes: Hi Gemini, > The ability to quit multiple threads at once also seems useful to me. > > One possibility would be if you do something like this, to open up all > your project files at once: > > C-x & C-x f /scp:server:project/worktree_a/*.el RET > > And then after you press RET, realize that you meant to type worktree_b > instead. > > Or after you press RET, realize that your network connection is too slow > for what you've asked Emacs to do, making you decide you'd like it to > give up. > > Or each of the threads starts reporting the same error, and you realize > none of them are going to work, and you want to make the error spam stop > so you can fix the problem. > > Right now the "Checking vc-registered" phase of multi-threaded > find-file hogs the global lock and makes Emacs unusable for a while if > you are loading many files at once; maybe that, or some other package in > your config which wasn't written with threading in mind and gets called > by your find-file threads, makes Emacs slow and goes on for too long, > and you want to make it stop so you can do something else. > > C-g is probably not the solution to these situations and I'm not sure > what is, but it would be nice to have some way to resolve them besides > restarting Emacs. You could enhance your thread.el. In the list of threads, one could mark threads, and send all of them the quit signal via a new command. Likely, this should happen only if you are in the main thread. So we also need a command which lets you switch to the main thread, wherever you are. C-g could be good for this, but I don't know whether there are undesired side effects. Hmm, this is the bug report. Shall we discuss it on emacs-devel? Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 30 08:34:17 2018 Received: (at 32502) by debbugs.gnu.org; 30 Aug 2018 12:34:17 +0000 Received: from localhost ([127.0.0.1]:38025 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvM9R-0004S3-DN for submit@debbugs.gnu.org; Thu, 30 Aug 2018 08:34:17 -0400 Received: from mout.gmx.net ([212.227.17.22]:57609) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvM9P-0004Rn-1Y for 32502@debbugs.gnu.org; Thu, 30 Aug 2018 08:34:15 -0400 Received: from detlef.gmx.de ([212.91.238.173]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MNf1y-1g1Qwv0Jic-007Fvw; Thu, 30 Aug 2018 14:34:07 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs 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> <87va7swcd3.fsf@gmx.de> Date: Thu, 30 Aug 2018 14:34:05 +0200 In-Reply-To: <87va7swcd3.fsf@gmx.de> (Michael Albinus's message of "Thu, 30 Aug 2018 09:19:04 +0200") Message-ID: <87h8jcvxs2.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:tksDizrQbN5oGXVK98UVL31hGt1eAvaz9bvcyYT93Fn/QpRVAky UjMkMyW4HX7Yxg1OT6RpFhXGYvZNS30QpGyCjXW0iVQfde12kfy+6xpxBh64pZF5Wihw9zC DQzQ9cuDOj2AX9vGxOCvdl1WT2LtxX+DX6fx6/ld5K5OC6fp4z6GbBsm8pL+0eBhWdKcSwc zxaDXbgw/T9UtzsVr5ccA== X-UI-Out-Filterresults: notjunk:1;V01:K0:oRIQLIt0864=:YkHsXwVLRmTb/8qeFJG3hu s/DdZVCWHEQb2R5R1DrbixA8tdmeLdMqHuH3VJW87NiMYZQ70ePYdaZ4zd/haawu2zEXXVnMb vlFw/9JlBKsL0/7nQjO8d5dRWkq5FFy29fYh9q5biCK+I6i/ZvbFdn6gItO3FSQJaoxbB80i2 CConzzsK89/sZb0dzttWyXs0fXOuD6pUPqwhSYvm8UEv+/TmryiO31P1OjhjlgMFniK/28THh IMNeP2etRhjPbefq2hlVi9D7lm4gSgPwtEMFoUMdHBS7RU2PPEMr41gWO34f7qULx22lbX5LB /s0ZvKBthQwOWuQGdvazVVodewcqT5SvFqcwA4aaxS9j7R62eE1WlJXdI6KSkXxgkilxrJPEj rmN5IjB/EKroYNS+96Rh4nJyql/5JMzIvBCzrMO2/vURLvM3tXvZs/NnUx56Vr6IoH+qWRzDI ZOAHFykxpG+Wwmz0cIk0xGr20H1ZOHMnHfNfSef65pYRYFG3bYTEHSGVGWpF5GyOf6An0Crg6 ZzIMrwqKvZVNLGRc4a/Z8s6rpuGbQ/mxK6MxJSYs1mICNUPF0+4v+lB/Vy1IpCS4uHIXCI1xX z6fFK/Lnmox+31MW/t8a1mmZw2IwuuX8UFjnFXMdGwkc5mlEHqvrwYaaA1To1SBii1ODyOAc9 npbZJHtspUkNbr0etCJ4yMC9caCluH3UGtOcl9ppcA9108Bf1WvFcfjpTR4QEyfePgNYkdYDY ODJlwkNJGgZ38askBSi/bfU+IubhhHeS717F0kKucBEGLBte4EwxGuUa2hDbZ/nKWzTk4Btig QuhJn9n X-Spam-Score: 4.2 (++++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Michael Albinus writes: > 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. [...] Content analysis details: (4.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.5 RCVD_IN_SORBS_HTTP RBL: SORBS: sender is open HTTP proxy server [212.91.238.173 listed in dnsbl.sorbs.net] 2.4 RCVD_IN_SORBS_SOCKS RBL: SORBS: sender is open SOCKS proxy server -0.0 SPF_PASS SPF: sender matches SPF record -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.17.22 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (michael.albinus[at]gmx.de) X-Debbugs-Envelope-To: 32502 Cc: Gemini Lasswell , 32502@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Michael Albinus writes: > 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. [...] Content analysis details: (3.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.17.22 listed in list.dnswl.org] 2.5 RCVD_IN_SORBS_HTTP RBL: SORBS: sender is open HTTP proxy server [212.91.238.173 listed in dnsbl.sorbs.net] 2.4 RCVD_IN_SORBS_SOCKS RBL: SORBS: sender is open SOCKS proxy server -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (michael.albinus[at]gmx.de) -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager Michael Albinus writes: > 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. I stay corrected: thread-join propagates also errors to the calling thread. I've modified Tramp not to propagate errors to the main thread. In find-file-noselect, thread-join is wrapped now by with-demoted-errors. Pushed to the feature/tramp-thread-safe branch. Gemini, could you pls check whether this works for you as expected? Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 30 08:34:33 2018 Received: (at control) by debbugs.gnu.org; 30 Aug 2018 12:34:34 +0000 Received: from localhost ([127.0.0.1]:38028 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvM9h-0004SY-OH for submit@debbugs.gnu.org; Thu, 30 Aug 2018 08:34:33 -0400 Received: from mout.gmx.net ([212.227.15.19]:52825) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvM9g-0004SJ-QL for control@debbugs.gnu.org; Thu, 30 Aug 2018 08:34:33 -0400 Received: from detlef.gmx.de ([212.91.238.173]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MFuC6-1g6t0u49LS-00EuUn for ; Thu, 30 Aug 2018 14:34:27 +0200 Date: Thu, 30 Aug 2018 14:34:26 +0200 Message-Id: <87ftywvxrh.fsf@gmx.de> To: control@debbugs.gnu.org From: Michael Albinus Subject: control message for bug #32502 X-Provags-ID: V03:K1:qWW27Cmugk7x2BykdSXrun8XgIOlFntJ1mVexOBla2jvMAP6Fqd EJ/cAWnZFbMWJN7PMsTC38FWleDrPx7MVYJl2SQbmQ9HgoK6Hwie0JPHuk7BDZYaePl2onN 0AV2gZOT68b6+Uz2P2CCBw2aoIpDH/j7YoE1BU9dQRowdiUJyWcdLse5SlasvjV4aiAHv+I JYHbUOOVwOKfEsOvJbogg== X-UI-Out-Filterresults: notjunk:1;V01:K0:Zk7d5Vga6Ss=:7+Uf3aeO0wdWa+XLNijcyJ dQ8aOWrKa87twH5lgI+73fYFdkNRHvck2CXttSXaHvYxOWO8ScHi9R6lkn3cogSAOl+pPC+Ar fBv2bx75P+hNS2pv/ofEyPKdez2YHFdNFU3X7rWtRfEH6J6jPaLlhRQ3uOEeJ3zBaEK/T0UNh l68sjkLzMsaSS2pY9shp/eJefoztL9DDmcs66TnnByX0bAUMaNR4WegF8va8qxDwSq5xMYUmb 88jFIPh4H66ydSUcPm8Yp+r9gjkozgTklO2I8WxoKQp7FYRblNuw+xebQnBWeU7hRSU4Cahyh Jl82JCcZ7iYsXfMl+tySyIVIRemRvHxBPUa2oQIO1XatBFgGOc8LeQU8wOMvzk0S15CHPo+dm fhnGGRFkv9K07z46BwFSjv9VpTEB2Q1fDM5uRnrhjs8ECGsRnu23/+oG9kk9OHPZiebCtF969 FDikxA6d950HM9yUJN9UFNKNtOACf1TfHaRXHIwLDI8DOeglFYnPmi/GFXiVaKKlbSmxCRx7D +regb/0xzT3OoF4LWVnENIyXHFhQUqJx1xS9jvKIQatIcf1Q6ATQ9c9OZnOVrc1eU6ksBUoyy 4BMWJ1G00uPthc1CEhKHLE2WEQT8W/BnN1V1T0i8alTlCXuZzQ3j/gQn9XwEYcuUV2hfHzT2G bjMb8fmbsICh635Wg55+Xfazq34gQmu+SXaTnEd9fq7tQmcrkpF6bXMqsgqDjjGO61LlwVYbL iqmZ5xtojNuPd7biGko3RmGk6F2HHAaGB+f4/hHowg6P64plQ+ym02ueNMQ= X-Spam-Score: 4.2 (++++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: tags 32502 fixed [...] Content analysis details: (4.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.5 RCVD_IN_SORBS_HTTP RBL: SORBS: sender is open HTTP proxy server [212.91.238.173 listed in dnsbl.sorbs.net] 2.4 RCVD_IN_SORBS_SOCKS RBL: SORBS: sender is open SOCKS proxy server -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (michael.albinus[at]gmx.de) -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.15.19 listed in list.dnswl.org] X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: tags 32502 fixed [...] Content analysis details: (3.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.15.19 listed in list.dnswl.org] 2.5 RCVD_IN_SORBS_HTTP RBL: SORBS: sender is open HTTP proxy server [212.91.238.173 listed in dnsbl.sorbs.net] 2.4 RCVD_IN_SORBS_SOCKS RBL: SORBS: sender is open SOCKS proxy server -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (michael.albinus[at]gmx.de) -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager tags 32502 fixed From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 30 09:19:26 2018 Received: (at 32502) by debbugs.gnu.org; 30 Aug 2018 13:19:26 +0000 Received: from localhost ([127.0.0.1]:38066 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvMr7-0007bd-VT for submit@debbugs.gnu.org; Thu, 30 Aug 2018 09:19:26 -0400 Received: from eggs.gnu.org ([208.118.235.92]:38722) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvMr6-0007bP-6E for 32502@debbugs.gnu.org; Thu, 30 Aug 2018 09:19:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fvMqx-0006HA-Th for 32502@debbugs.gnu.org; Thu, 30 Aug 2018 09:19:19 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46222) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fvMqx-0006H6-R0; Thu, 30 Aug 2018 09:19:15 -0400 Received: from [176.228.60.248] (port=1906 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fvMqx-0008U1-D7; Thu, 30 Aug 2018 09:19:15 -0400 Date: Thu, 30 Aug 2018 16:18:59 +0300 Message-Id: <83va7s0z7g.fsf@gnu.org> From: Eli Zaretskii To: Michael Albinus In-reply-to: <87zhx4wcsp.fsf@gmx.de> (message from Michael Albinus on Thu, 30 Aug 2018 09:09:42 +0200) Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> <87efemp0yz.fsf@runbox.com> <87pny1xiv5.fsf@gmx.de> <83in3t2lcl.fsf@gnu.org> <87lg8pxgs6.fsf@gmx.de> <83h8jd2jh6.fsf@gnu.org> <87d0u1xfek.fsf@gmx.de> <878t4oylcj.fsf@gmx.de> <874lfcyjpn.fsf@gmx.de> <834lfc37ji.fsf@gnu.org> <87zhx4wcsp.fsf@gmx.de> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 32502 Cc: gazally@runbox.com, 32502@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: Michael Albinus > Cc: gazally@runbox.com, 32502@debbugs.gnu.org > Date: Thu, 30 Aug 2018 09:09:42 +0200 > > Eli Zaretskii writes: > > >> So it looks like you are right: we cannot send signals to the main > >> thread. Is this acceptable? > > > > Yes, I think so, but let's document that. > > Sounds to me like a serious restriction. When something happens in a > thread, I want to know it. There isn't even a message about the error. If we want to announce the errors to the main thread, we can use methods other than signaling an error. For example, we could inject a special event into the input queue, similarly to how we produce help-echo and other special events. Fsignal is a very blunt weapon, its main effect is to throw to top level. Why would we want to do that _in_the_main_thread_ when the problem happened in another thread? That's disruptive, and could even mean that the user will lose their edits. Not nice, IMO. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 30 09:24:15 2018 Received: (at 32502) by debbugs.gnu.org; 30 Aug 2018 13:24:15 +0000 Received: from localhost ([127.0.0.1]:38075 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvMvn-0007kE-63 for submit@debbugs.gnu.org; Thu, 30 Aug 2018 09:24:15 -0400 Received: from eggs.gnu.org ([208.118.235.92]:39675) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvMvl-0007k0-Ox for 32502@debbugs.gnu.org; Thu, 30 Aug 2018 09:24:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fvMvd-0000MA-KZ for 32502@debbugs.gnu.org; Thu, 30 Aug 2018 09:24:08 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46269) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fvMvd-0000M6-Hb; Thu, 30 Aug 2018 09:24:05 -0400 Received: from [176.228.60.248] (port=2211 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fvMvd-0000PJ-2a; Thu, 30 Aug 2018 09:24:05 -0400 Date: Thu, 30 Aug 2018 16:23:50 +0300 Message-Id: <83sh2w0yzd.fsf@gnu.org> From: Eli Zaretskii To: Michael Albinus In-reply-to: <87r2igw6kv.fsf@gmx.de> (message from Michael Albinus on Thu, 30 Aug 2018 11:24:00 +0200) Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> <83pny67h2y.fsf@gnu.org> <8736v2bfzx.fsf@gmx.de> <83muta77li.fsf@gnu.org> <87a7p9p77s.fsf@runbox.com> <87r2igw6kv.fsf@gmx.de> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 32502 Cc: gazally@runbox.com, 32502@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: Michael Albinus > Cc: Eli Zaretskii , 32502@debbugs.gnu.org > Date: Thu, 30 Aug 2018 11:24:00 +0200 > > So we also need a command which lets you switch to the main thread, > wherever you are. This would need some infrastructure that currently doesn't exist. Wed can tell the current thread to yield, but we have no way of designating another thread that will run when the first one yields. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 30 09:28:38 2018 Received: (at 32502) by debbugs.gnu.org; 30 Aug 2018 13:28:38 +0000 Received: from localhost ([127.0.0.1]:38086 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvN02-0007qs-0E for submit@debbugs.gnu.org; Thu, 30 Aug 2018 09:28:38 -0400 Received: from mout.gmx.net ([212.227.15.19]:59897) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvN00-0007qZ-0T for 32502@debbugs.gnu.org; Thu, 30 Aug 2018 09:28:36 -0400 Received: from detlef.gmx.de ([212.91.238.173]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MgKUo-1gFdfO0bW2-00Ni5Z; Thu, 30 Aug 2018 15:28:28 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> <83pny67h2y.fsf@gnu.org> <8736v2bfzx.fsf@gmx.de> <83muta77li.fsf@gnu.org> <87a7p9p77s.fsf@runbox.com> <87r2igw6kv.fsf@gmx.de> <83sh2w0yzd.fsf@gnu.org> Date: Thu, 30 Aug 2018 15:28:25 +0200 In-Reply-To: <83sh2w0yzd.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 30 Aug 2018 16:23:50 +0300") Message-ID: <87sh2wrnk6.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:XWSlMEIwuiSPMZxkppzvMrgIyhKy45fhdaKlW2e/37Gt94v2J3A gLEWUxPKm3i6IdG571W93a8U7LfnD+9a87yND6dLOQkQZXAdAP8HhZlhBnCzWDBWvDah8kU Kq0FJRSzIF/hg6lxcUCKZEbkSq+d7ookblv5L67CIXGsIpFe81TdNEBUW8h/nE+XscNK6EC qSHwLqn9n9H/6dyU/Nlsg== X-UI-Out-Filterresults: notjunk:1;V01:K0:prxqQEFcCts=:saflcrTb9deSzAl4wvNNSc 58DRsdKHLDwJJeE2yK7W7cYXt2C3iiUs8MnvNuUn3TZzybzqPDrUmjBCyzI476ngkoFffWL0E em0isdYDYUqkx7uhMxXpxj2SQqn1gOsFmpFo37AQCOj8EImVChYge1pBvcO/Tdg4bwI4PJZNF k56CrD8w9GU/ooqEOwHUFtb6u0DGo+rqttFvOvgB9QWqj782tmJJ+uqXMiuOCoON55tlW9aLu UiWahDKIm2zQzqwF6grwwCidhun9Pd7wcxsiIErVARY1O9E5fejJUmeR0shU3TnnvTwDLRpbI TqtKxX9jnflmKA9DUuXBhnXDVO9/lrlN6KgjIHnsOjwv7BGyReFlXnkoH9OULdAJslGSU70jS 5MDvLo2xUjGgzIyCB0DIcrk3vBbDoyT1Ty0syivpQls/+8FFecFM7INCfsFCaXvkC1C720Jjr QSH2LodaAT6ldur3oVTZcLjAq6zoJLZAyr7JiJmqWDcmvHGFHy9yp4n5hlZGJDi08rbP/a/f5 r645ZJPjBOH415D9AqA7GJn6vgXJT5Ve08ssQpUlCf6NihzRjLL154YX3YF4W/DAPpUdqCi88 5jE879s6pLRSw0rhtyJhoaamLnzwThyMuF9mQ1UYbqm7VPsKp+qa9oST1wwIOeNIwr0DDs7v/ vD2SLwuk1tco/b1Von28GB375e1S8ed62vW2HMwT8V9r3zrpm+iyuwFIyjCWHZzfs6GRhbzOP E69vjHvWlQtC9r9KAGnL1R+x6PNLueS+Bfuir6SAeXmqz7l5y8GmH+9U0JkpcNS1mAqLH/rVJ YanFnrh X-Spam-Score: 4.2 (++++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii writes: >> So we also need a command which lets you switch to the main thread, >> wherever you are. > > This would need some infrastructure that currently doesn't exist. Wed > can tell the current thread to yield, but we have no way of > designating another thread that will run when the first one yields. [...] Content analysis details: (4.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.15.19 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (michael.albinus[at]gmx.de) 2.5 RCVD_IN_SORBS_HTTP RBL: SORBS: sender is open HTTP proxy server [212.91.238.173 listed in dnsbl.sorbs.net] 2.4 RCVD_IN_SORBS_SOCKS RBL: SORBS: sender is open SOCKS proxy server X-Debbugs-Envelope-To: 32502 Cc: gazally@runbox.com, 32502@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii writes: >> So we also need a command which lets you switch to the main thread, >> wherever you are. > > This would need some infrastructure that currently doesn't exist. Wed > can tell the current thread to yield, but we have no way of > designating another thread that will run when the first one yields. [...] Content analysis details: (3.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.15.19 listed in list.dnswl.org] 2.5 RCVD_IN_SORBS_HTTP RBL: SORBS: sender is open HTTP proxy server [212.91.238.173 listed in dnsbl.sorbs.net] 2.4 RCVD_IN_SORBS_SOCKS RBL: SORBS: sender is open SOCKS proxy server -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (michael.albinus[at]gmx.de) -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager Eli Zaretskii writes: >> So we also need a command which lets you switch to the main thread, >> wherever you are. > > This would need some infrastructure that currently doesn't exist. Wed > can tell the current thread to yield, but we have no way of > designating another thread that will run when the first one yields. Of course. But in the "User interaction from multiple threads" thread there was also the proposal to delegate tasks from a thread to the main thread. So there seems to be also other use cases. Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 30 09:33:11 2018 Received: (at 32502) by debbugs.gnu.org; 30 Aug 2018 13:33:11 +0000 Received: from localhost ([127.0.0.1]:38104 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvN4R-00080t-KW for submit@debbugs.gnu.org; Thu, 30 Aug 2018 09:33:11 -0400 Received: from mout.gmx.net ([212.227.17.22]:60791) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvN4P-00080e-JE for 32502@debbugs.gnu.org; Thu, 30 Aug 2018 09:33:09 -0400 Received: from detlef.gmx.de ([212.91.238.173]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MYbFe-1gPUsw2kz4-00VO4V; Thu, 30 Aug 2018 15:33:00 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> <87efemp0yz.fsf@runbox.com> <87pny1xiv5.fsf@gmx.de> <83in3t2lcl.fsf@gnu.org> <87lg8pxgs6.fsf@gmx.de> <83h8jd2jh6.fsf@gnu.org> <87d0u1xfek.fsf@gmx.de> <878t4oylcj.fsf@gmx.de> <874lfcyjpn.fsf@gmx.de> <834lfc37ji.fsf@gnu.org> <87zhx4wcsp.fsf@gmx.de> <83va7s0z7g.fsf@gnu.org> Date: Thu, 30 Aug 2018 15:32:58 +0200 In-Reply-To: <83va7s0z7g.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 30 Aug 2018 16:18:59 +0300") Message-ID: <87o9dkrncl.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:9+L4AQbtxfuS3Jy8EzPYTOyp3yAF/5e4g9hJrAZM/qWG3oftvb8 W3IRXvmEJI25MrVDu5gdafxobOfbRO5pTtL5LznENSSbnQb2e4Nh4JjZaYYyVgFVWeR1N15 4GGhbEy2yVodV3oROo+B6U5utpTCoxTUXu+7pHPl45aIKdREvbSWCuUgYTS3ukfAg7GBNmP 98T1bQPPeuV3nQNlGYnqg== X-UI-Out-Filterresults: notjunk:1;V01:K0:0owuomh46o4=:vzanDVOboYXwDFzf/+aiRL XApFAq/NluChxMNS+61CoZxmEC19kFANJ0qco0tCx8qxgAhye00OD5sN49BfoB82qPcNd6djn xIfobTSBj/zlHwS87NbY91bheEMCSZIHtOqaFfgdD70W1+2aSOJl/aNH/7DzgnCqmfGMBDrEf rQYoc65aSIngIKougXnli3y7YcmErsfL3Bd1rcZYfWzGDuQ1k9fpm3UrS5vI2E5SN/qOp8RSr 9i/TZLssbREK+naL7L+eTPi7REOM+M5Dbg7s43lTBAIiS1jw26O2VdsBKg/K6XccRMTZvdLFr X86CBZBBNlnMAN0OpRnWDQLvgXjVNLYC626F4urR8KZVYNOmbIvIN7qvrh71RSZcoQm8B7oBz QBh3l92U9sO8d34gtm36kgOiaqMFQR/UOG5RQKhgK3kmwI33dxLs11tzVv5Fg6cVe4TCe5ZlR HI3n3y8Eq2naEf5QWNbZmRG5+lAt2VV3oexOu6K7YG173VxeAJlf/6BiuoBhSYva+mReATili SNynX1/jpP1e4QkY+eEDA/AjnHpqT4UYEY0OvUHyC1F+jgHSaJPLOt5ekbw3q5EOOdoN+UzZw dVdulm7JZWSgVkbyL4U5aacxHpJg4fLv/+LiuO7BSaAM9TH+nt1lJVB6bMN7Rady7OR8WnW8S eoUz/OfDeiB0ltsO+bvbSkQImFm8ZSUq2/Nuvhx4X1c7YRq3f9nPan1mPhsjGGUQ8np7BfCpJ 1LppXWoECNeLNcRjEvo5lEdx5CmbLTBPw+inLXT8GGJgspfDdwdjqfpQnMifPPQArfAHrQRgh /94gh/n X-Spam-Score: 4.2 (++++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii writes: >> >> So it looks like you are right: we cannot send signals to the main >> >> thread. Is this acceptable? >> > >> > Yes, I think so, but let's document that. I'm just doing it. [...] Content analysis details: (4.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.5 RCVD_IN_SORBS_HTTP RBL: SORBS: sender is open HTTP proxy server [212.91.238.173 listed in dnsbl.sorbs.net] 2.4 RCVD_IN_SORBS_SOCKS RBL: SORBS: sender is open SOCKS proxy server -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (michael.albinus[at]gmx.de) -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.17.22 listed in list.dnswl.org] X-Debbugs-Envelope-To: 32502 Cc: gazally@runbox.com, 32502@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii writes: >> >> So it looks like you are right: we cannot send signals to the main >> >> thread. Is this acceptable? >> > >> > Yes, I think so, but let's document that. I'm just doing it. [...] Content analysis details: (3.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.17.22 listed in list.dnswl.org] 2.5 RCVD_IN_SORBS_HTTP RBL: SORBS: sender is open HTTP proxy server [212.91.238.173 listed in dnsbl.sorbs.net] 2.4 RCVD_IN_SORBS_SOCKS RBL: SORBS: sender is open SOCKS proxy server -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (michael.albinus[at]gmx.de) -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager Eli Zaretskii writes: >> >> So it looks like you are right: we cannot send signals to the main >> >> thread. Is this acceptable? >> > >> > Yes, I think so, but let's document that. I'm just doing it. >> Sounds to me like a serious restriction. When something happens in a >> thread, I want to know it. There isn't even a message about the error. > > If we want to announce the errors to the main thread, we can use > methods other than signaling an error. For example, we could inject > a special event into the input queue, similarly to how we produce > help-echo and other special events. I'm just changing thread-signal such a way that it ignores silently signals sent to the main thread. Shall I implement this event injection instead? And what shall be done with this event in the main thread? Just writing an error message, or some kind of handling? Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 30 09:51:41 2018 Received: (at 32502) by debbugs.gnu.org; 30 Aug 2018 13:51:41 +0000 Received: from localhost ([127.0.0.1]:38112 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvNMK-0008U2-PN for submit@debbugs.gnu.org; Thu, 30 Aug 2018 09:51:40 -0400 Received: from eggs.gnu.org ([208.118.235.92]:48026) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvNMJ-0008Tc-Ef for 32502@debbugs.gnu.org; Thu, 30 Aug 2018 09:51:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fvNMA-0000Ir-5P for 32502@debbugs.gnu.org; Thu, 30 Aug 2018 09:51:34 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46821) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fvNMA-0000In-0v; Thu, 30 Aug 2018 09:51:30 -0400 Received: from [176.228.60.248] (port=3933 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fvNM9-0001hU-KA; Thu, 30 Aug 2018 09:51:29 -0400 Date: Thu, 30 Aug 2018 16:51:14 +0300 Message-Id: <83mut40xpp.fsf@gnu.org> From: Eli Zaretskii To: Michael Albinus In-reply-to: <87o9dkrncl.fsf@gmx.de> (message from Michael Albinus on Thu, 30 Aug 2018 15:32:58 +0200) Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> <87efemp0yz.fsf@runbox.com> <87pny1xiv5.fsf@gmx.de> <83in3t2lcl.fsf@gnu.org> <87lg8pxgs6.fsf@gmx.de> <83h8jd2jh6.fsf@gnu.org> <87d0u1xfek.fsf@gmx.de> <878t4oylcj.fsf@gmx.de> <874lfcyjpn.fsf@gmx.de> <834lfc37ji.fsf@gnu.org> <87zhx4wcsp.fsf@gmx.de> <83va7s0z7g.fsf@gnu.org> <87o9dkrncl.fsf@gmx.de> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 32502 Cc: gazally@runbox.com, 32502@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: Michael Albinus > Cc: gazally@runbox.com, 32502@debbugs.gnu.org > Date: Thu, 30 Aug 2018 15:32:58 +0200 > > > If we want to announce the errors to the main thread, we can use > > methods other than signaling an error. For example, we could inject > > a special event into the input queue, similarly to how we produce > > help-echo and other special events. > > I'm just changing thread-signal such a way that it ignores silently > signals sent to the main thread. Shall I implement this event injection > instead? I don't know. I guess it depends on how important is it to show the errors nicely. You could leave signals for now and use the events idea later as an enhancement. > And what shall be done with this event in the main thread? Just writing > an error message, or some kind of handling? Yes, displaying a message would be a good starting point, I think. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 30 10:00:07 2018 Received: (at 32502) by debbugs.gnu.org; 30 Aug 2018 14:00:07 +0000 Received: from localhost ([127.0.0.1]:39237 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvNUU-0000Xi-WD for submit@debbugs.gnu.org; Thu, 30 Aug 2018 10:00:07 -0400 Received: from mout.gmx.net ([212.227.15.18]:40535) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvNUR-0000Wb-Ij for 32502@debbugs.gnu.org; Thu, 30 Aug 2018 10:00:03 -0400 Received: from detlef.gmx.de ([212.91.238.173]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MfW5D-1gIexc1rAZ-00P4nD; Thu, 30 Aug 2018 15:59:55 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> <87efemp0yz.fsf@runbox.com> <87pny1xiv5.fsf@gmx.de> <83in3t2lcl.fsf@gnu.org> <87lg8pxgs6.fsf@gmx.de> <83h8jd2jh6.fsf@gnu.org> <87d0u1xfek.fsf@gmx.de> <878t4oylcj.fsf@gmx.de> <874lfcyjpn.fsf@gmx.de> <834lfc37ji.fsf@gnu.org> <87zhx4wcsp.fsf@gmx.de> <83va7s0z7g.fsf@gnu.org> <87o9dkrncl.fsf@gmx.de> <83mut40xpp.fsf@gnu.org> Date: Thu, 30 Aug 2018 15:59:54 +0200 In-Reply-To: <83mut40xpp.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 30 Aug 2018 16:51:14 +0300") Message-ID: <87h8jcvtt1.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:IBVHd4cx0oxZw9CZhNHcs9bgrdBqrgwNss4RxUWRSb9onZah7LF mc7Wa65ULg3WGrggGG++pOArLS1WoEPRP8E8fBxe/D11i4wEEmvJI6gHifn72uM5TXyuon+ ybfGDmYqcbCt7sG8TeCJJVV6YC1l8ZDuioCYIVra3iJZRvWHO9pD6sxMbra+MboSkIWZYHQ urwVy1rAnOtKWq8+e1hog== X-UI-Out-Filterresults: notjunk:1;V01:K0:ph++JOaYbWU=:ttsBWyuV6J73BU/1OKVH32 6uHmpwcqdHo0ZK5OJQYqyn/T0mubdn+QG5fvjqrCkSNo2relXBfhiSTa6RyF33q38jfEh7qO8 jXjAjnMUrmyOyEqjBZczgh/NLdUxvxFw+Dc1oWv8FwwwyFg5hXpUHWxg4fVVN791hD5acLRsO h2OXWYhcvIqf4lnLCTq2rI9cdYA1PX3uhYfcJAcboVC8sokLu39jMbLqMRkshV3vy63ThQs6n IgFM2B23qXEyUyjyzEX4h6Xgf175PKS6Gvh/6TVg6rg5IIIp7BBvRbWxuz3MTI++0M9N5PfbD PtInz/1w5/R400+abkOqpXtH96EubvuuM20VLlBchUbP7P17ItG2DZqocVx0it18N0GGnsymm F+683qWbSzWC/yols6Y7odcKak96FX8igI12/uU/9UZs8LcsPgHZxjEeL6SXqQjGWx1OfG+YM PrwU1T+q1qSA2QijHNstvXqC30aaOeMWK6HFt0jKcrinbHnOvZsRrtjIICUq+bjz7g21Bw1nu jxbPCD9AsW6nND3iso7ByrHAHZ9NUowKJCotgmam2pwzdinb7Ts4zWnJ4M38b47+qYFmi8Nqp joBcCCDjaZfr7Qvw0xcH0/Nj1JJDttzHD23m4Rm61usP5PYI2fOAUdZy5qcrQvVTA4GdetQmJ NAYdDQ7tQvjTpsUKqrLFXgzYbH1hvMlDXKpdMuiWW9oRptMRsDqlUAtrXo+FHax3eD1+VOWOn Gzq/u6eDSm4ezFECMwoXV+267JOhElkKB4d7E2Nlrd01PHKjdCZuSwtzYyHonvh0YqZBzlZIh Zc60G7L X-Spam-Score: 4.2 (++++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii writes: >> I'm just changing thread-signal such a way that it ignores silently >> signals sent to the main thread. Shall I implement this event injection >> instead? > > I don't know. I guess it depends on how important is it to show the > errors nicely. You could leave signals for now and use the events > idea later as an enhancement. [...] Content analysis details: (4.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.15.18 listed in list.dnswl.org] 2.5 RCVD_IN_SORBS_HTTP RBL: SORBS: sender is open HTTP proxy server [212.91.238.173 listed in dnsbl.sorbs.net] 2.4 RCVD_IN_SORBS_SOCKS RBL: SORBS: sender is open SOCKS proxy server -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (michael.albinus[at]gmx.de) X-Debbugs-Envelope-To: 32502 Cc: gazally@runbox.com, 32502@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii writes: >> I'm just changing thread-signal such a way that it ignores silently >> signals sent to the main thread. Shall I implement this event injection >> instead? > > I don't know. I guess it depends on how important is it to show the > errors nicely. You could leave signals for now and use the events > idea later as an enhancement. [...] Content analysis details: (3.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.15.18 listed in list.dnswl.org] 2.5 RCVD_IN_SORBS_HTTP RBL: SORBS: sender is open HTTP proxy server [212.91.238.173 listed in dnsbl.sorbs.net] 2.4 RCVD_IN_SORBS_SOCKS RBL: SORBS: sender is open SOCKS proxy server -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (michael.albinus[at]gmx.de) -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager Eli Zaretskii writes: >> I'm just changing thread-signal such a way that it ignores silently >> signals sent to the main thread. Shall I implement this event injection >> instead? > > I don't know. I guess it depends on how important is it to show the > errors nicely. You could leave signals for now and use the events > idea later as an enhancement. I will see how easy it is. I have experience with dbus-event and file-notify-event; it shouldn't too hard for me to implement thread-event. >> And what shall be done with this event in the main thread? Just writing >> an error message, or some kind of handling? > > Yes, displaying a message would be a good starting point, I think. Since special events have their own handler, it will be simple to change later. Will start with echoing the error message. Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 30 12:48:31 2018 Received: (at 32502) by debbugs.gnu.org; 30 Aug 2018 16:48:32 +0000 Received: from localhost ([127.0.0.1]:39333 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvQ7T-0004go-J7 for submit@debbugs.gnu.org; Thu, 30 Aug 2018 12:48:31 -0400 Received: from mout.gmx.net ([212.227.17.21]:41185) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvQ7R-0004gW-Qa for 32502@debbugs.gnu.org; Thu, 30 Aug 2018 12:48:30 -0400 Received: from detlef.gmx.de ([212.91.238.173]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MEo4s-1g6yZr1hVK-00G4jj; Thu, 30 Aug 2018 18:48:21 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> <87efemp0yz.fsf@runbox.com> <87pny1xiv5.fsf@gmx.de> <83in3t2lcl.fsf@gnu.org> <87lg8pxgs6.fsf@gmx.de> <83h8jd2jh6.fsf@gnu.org> <87d0u1xfek.fsf@gmx.de> <878t4oylcj.fsf@gmx.de> <874lfcyjpn.fsf@gmx.de> <834lfc37ji.fsf@gnu.org> <87zhx4wcsp.fsf@gmx.de> <83va7s0z7g.fsf@gnu.org> <87o9dkrncl.fsf@gmx.de> <83mut40xpp.fsf@gnu.org> <87h8jcvtt1.fsf@gmx.de> Date: Thu, 30 Aug 2018 18:48:19 +0200 In-Reply-To: <87h8jcvtt1.fsf@gmx.de> (Michael Albinus's message of "Thu, 30 Aug 2018 15:59:54 +0200") Message-ID: <87h8jb7qcs.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Provags-ID: V03:K1:HsfuY8R/oO886uE9+oc6bBcaDAhsq2gC8fwRaeAyuLuD9w2Otk/ 5HKt9ktRsMr9w+gVJFQ/AMKdkDxlHwYJgGkBf8mgUullXU7+dLFvBnrXFJyaCvmp0oB21kr gOMnCsUHzdUGfr0OwGqkeSPEODqM66R+XON7zwfpWNDHGER3JNphwOtuw4ktnlw8nC2xqT0 uokLboqMPM43QEVvGQB5Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:TZTwOkrQsbY=:zT9RXTH/i7298S54BhPVLC LZJCkFUhg+cf4fabvuOeLsJ8YKE3dGCCRpogxLqmRHKcMnYHTpsdG3Hd29nMj7QaA0ipljmKQ 76VJI+BsjzwzmPEuU90g+zJ6HNnmt5xm6G6twfTi86iqvTxeB7VWqWhd5TZJThLKhCPLbHs1n WgovMFi8VvRkgi5s1SNAXJAVap8J9du55GP1Ya9rboyRqn3PlbqSa+OK6PQEvIPWZ5xkLlPvK jmYedfxrVCykULHamlfBAvyuTKCoyOXv8MjjICt9cVPjdQBrovp7GxgUai6ex0kXYMTR6CfEF s4kstPh2Bq9d1kr7OQ+YQodRk+vdApmDmI6/IaHNpXpb62lhUkQmmAHOzkqgwM3j13twNT8L8 nkuZYzFf/6krcYYlGhzLvdXkdys4XI1neFaqLCgMDPJhGJ8YHe/HxheQ7I7t0AMspn45+RA8g DANDeRMI9KcPIUktopLSmgN6F9qt/KCpep67EYh4oZ0O2Lpn6Gq6nNQzot/MT7M37isWqmf3M A5UKNlAAh4x3QTHFfWmLX9il73GnoR3dER3HzhKKgNaRtKg7/tYUF2ctpsu2uqGt+JzWWCSOV +9gbhF9jqZ25EBKR+FEaxA8tpXCSVb5kkCf3wEHkBtx1b4O5/uKZQ8oHwbP6zd/1fyUiqLS9S BoIn+ifXnnxhPnUkDfabYlcVoQAW9XVzSHJWSBxjwHQBdsMuat9ew7xRGKfluwNu60yseqO0n AppVq27XYj/qwkkt2QtjLVLErU7Jptfn9WCxAaThon8ZKqTJqJCYmBj/tn8= X-Spam-Score: 4.2 (++++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Michael Albinus writes: >>> I'm just changing thread-signal such a way that it ignores silently >>> signals sent to the main thread. Shall I implement this event injection >>> instead? >> >> I don't know. I guess it depends on how important is it to show the >> errors nicely. You could leave signals for now and use the events >> idea later as an enhancement. > > I will see how easy it is. I have experience with dbus-event and > file-notify-event; it shouldn't too hard for me to implement thread-event. > >>> And what shall be done with this event in the main thread? Just writing >>> an error message, or some kind of handling? >> >> Yes, displaying a message would be a good starting point, I think. > > Since special events have their own handler, it will be simple to change > later. Will start with echoing the error message. [...] Content analysis details: (4.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (michael.albinus[at]gmx.de) -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.17.21 listed in list.dnswl.org] 2.5 RCVD_IN_SORBS_HTTP RBL: SORBS: sender is open HTTP proxy server [212.91.238.173 listed in dnsbl.sorbs.net] 2.4 RCVD_IN_SORBS_SOCKS RBL: SORBS: sender is open SOCKS proxy server X-Debbugs-Envelope-To: 32502 Cc: gazally@runbox.com, 32502@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Michael Albinus writes: >>> I'm just changing thread-signal such a way that it ignores silently >>> signals sent to the main thread. Shall I implement this event injection >>> instead? >> >> I don't know. I guess it depends on how important is it to show the >> errors nicely. You could leave signals for now and use the events >> idea later as an enhancement. > > I will see how easy it is. I have experience with dbus-event and > file-notify-event; it shouldn't too hard for me to implement thread-event. > >>> And what shall be done with this event in the main thread? Just writing >>> an error message, or some kind of handling? >> >> Yes, displaying a message would be a good starting point, I think. > > Since special events have their own handler, it will be simple to change > later. Will start with echoing the error message. [...] Content analysis details: (3.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.17.21 listed in list.dnswl.org] 2.5 RCVD_IN_SORBS_HTTP RBL: SORBS: sender is open HTTP proxy server [212.91.238.173 listed in dnsbl.sorbs.net] 2.4 RCVD_IN_SORBS_SOCKS RBL: SORBS: sender is open SOCKS proxy server -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (michael.albinus[at]gmx.de) -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager --=-=-= Content-Type: text/plain Michael Albinus writes: >>> I'm just changing thread-signal such a way that it ignores silently >>> signals sent to the main thread. Shall I implement this event injection >>> instead? >> >> I don't know. I guess it depends on how important is it to show the >> errors nicely. You could leave signals for now and use the events >> idea later as an enhancement. > > I will see how easy it is. I have experience with dbus-event and > file-notify-event; it shouldn't too hard for me to implement thread-event. > >>> And what shall be done with this event in the main thread? Just writing >>> an error message, or some kind of handling? >> >> Yes, displaying a message would be a good starting point, I think. > > Since special events have their own handler, it will be simple to change > later. Will start with echoing the error message. Appended is a first implementation. Comments? Best regards, Michael. --=-=-= Content-Type: text/plain Content-Disposition: attachment diff --git a/doc/lispref/threads.texi b/doc/lispref/threads.texi index 58a3a918ef..9830198411 100644 --- a/doc/lispref/threads.texi +++ b/doc/lispref/threads.texi @@ -88,14 +88,8 @@ Basic Thread Functions @code{condition-wait}, or @code{thread-join}; @code{thread-signal} will unblock it. -Since signal handlers in Emacs are located in the main thread, a -signal must be propagated there in order to become visible. The -second @code{signal} call let the thread die: - -@example -(thread-signal main-thread 'error data) -(signal 'error data) -@end example +If @var{thread} is the main thread, the signal is not propagated +there. Instead, it is shown as message in the main thread. @end defun @defun thread-yield diff --git a/src/keyboard.c b/src/keyboard.c index 7fafb41fcc..008d3b9d7c 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -2827,6 +2827,9 @@ read_char (int commandflag, Lisp_Object map, #endif #ifdef USE_FILE_NOTIFY || EQ (XCAR (c), Qfile_notify) +#endif +#ifdef THREADS_ENABLED + || EQ (XCAR (c), Qthread_event) #endif || EQ (XCAR (c), Qconfig_changed_event)) && !end_time) @@ -3739,7 +3742,7 @@ kbd_buffer_get_event (KBOARD **kbp, } #endif /* subprocesses */ -#if !defined HAVE_DBUS && !defined USE_FILE_NOTIFY +#if !defined HAVE_DBUS && !defined USE_FILE_NOTIFY && !defined THREADS_ENABLED if (noninteractive /* In case we are running as a daemon, only do this before detaching from the terminal. */ @@ -3750,7 +3753,7 @@ kbd_buffer_get_event (KBOARD **kbp, *kbp = current_kboard; return obj; } -#endif /* !defined HAVE_DBUS && !defined USE_FILE_NOTIFY */ +#endif /* !defined HAVE_DBUS && !defined USE_FILE_NOTIFY && !defined THREADS_ENABLED */ /* Wait until there is input available. */ for (;;) @@ -3900,6 +3903,9 @@ kbd_buffer_get_event (KBOARD **kbp, #ifdef HAVE_DBUS case DBUS_EVENT: #endif +#ifdef THREADS_ENABLED + case THREAD_EVENT: +#endif #ifdef HAVE_XWIDGETS case XWIDGET_EVENT: #endif @@ -5983,6 +5989,13 @@ make_lispy_event (struct input_event *event) } #endif /* HAVE_DBUS */ +#ifdef THREADS_ENABLED + case THREAD_EVENT: + { + return Fcons (Qthread_event, event->arg); + } +#endif /* THREADS_ENABLED */ + #ifdef HAVE_XWIDGETS case XWIDGET_EVENT: { @@ -11078,6 +11091,10 @@ syms_of_keyboard (void) DEFSYM (Qdbus_event, "dbus-event"); #endif +#ifdef THREADS_ENABLED + DEFSYM (Qthread_event, "thread-event"); +#endif + #ifdef HAVE_XWIDGETS DEFSYM (Qxwidget_event, "xwidget-event"); #endif @@ -11929,6 +11946,12 @@ keys_of_keyboard (void) "dbus-handle-event"); #endif +#ifdef THREADS_ENABLED + /* Define a special event which is raised for thread signals. */ + initial_define_lispy_key (Vspecial_event_map, "thread-event", + "thread-handle-event"); +#endif + #ifdef USE_FILE_NOTIFY /* Define a special event which is raised for notification callback functions. */ diff --git a/src/termhooks.h b/src/termhooks.h index 160bd2f480..8b5f648b43 100644 --- a/src/termhooks.h +++ b/src/termhooks.h @@ -222,6 +222,10 @@ enum event_kind , DBUS_EVENT #endif +#ifdef THREADS_ENABLED + , THREAD_EVENT +#endif + , CONFIG_CHANGED_EVENT #ifdef HAVE_NTGUI diff --git a/src/thread.c b/src/thread.c index 1c73d93865..0234f65e02 100644 --- a/src/thread.c +++ b/src/thread.c @@ -25,6 +25,7 @@ along with GNU Emacs. If not, see . */ #include "process.h" #include "coding.h" #include "syssignal.h" +#include "keyboard.h" static struct thread_state main_thread; @@ -34,7 +35,6 @@ static struct thread_state *all_threads = &main_thread; static sys_mutex_t global_lock; -extern int poll_suppress_count; extern volatile int interrupt_input_blocked; @@ -863,7 +863,8 @@ DEFUN ("thread-signal", Fthread_signal, Sthread_signal, 3, 3, 0, This acts like `signal', but arranges for the signal to be raised in THREAD. If THREAD is the current thread, acts just like `signal'. This will interrupt a blocked call to `mutex-lock', `condition-wait', -or `thread-join' in the target thread. */) +or `thread-join' in the target thread. +Signals to the main thread are ignored quietly. */) (Lisp_Object thread, Lisp_Object error_symbol, Lisp_Object data) { struct thread_state *tstate; @@ -874,13 +875,29 @@ or `thread-join' in the target thread. */) if (tstate == current_thread) Fsignal (error_symbol, data); - /* What to do if thread is already signaled? */ - /* What if error_symbol is Qnil? */ - tstate->error_symbol = error_symbol; - tstate->error_data = data; + if (main_thread_p (tstate)) + { + /* Construct an event. */ + struct input_event event; + EVENT_INIT (event); + event.kind = THREAD_EVENT; + event.frame_or_window = Qnil; + event.arg = list3 (Fcurrent_thread (), error_symbol, data); + + /* Store it into the input event queue. */ + kbd_buffer_store_event (&event); + } + + else + { + /* What to do if thread is already signaled? */ + /* What if error_symbol is Qnil? */ + tstate->error_symbol = error_symbol; + tstate->error_data = data; - if (tstate->wait_condvar) - flush_stack_call_func (thread_signal_callback, tstate); + if (tstate->wait_condvar) + flush_stack_call_func (thread_signal_callback, tstate); + } return Qnil; } --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 30 13:45:10 2018 Received: (at 32502) by debbugs.gnu.org; 30 Aug 2018 17:45:10 +0000 Received: from localhost ([127.0.0.1]:39354 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvR0I-00064G-HT for submit@debbugs.gnu.org; Thu, 30 Aug 2018 13:45:10 -0400 Received: from eggs.gnu.org ([208.118.235.92]:41653) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvR0F-00063w-54 for 32502@debbugs.gnu.org; Thu, 30 Aug 2018 13:45:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fvR06-0004WF-Mq for 32502@debbugs.gnu.org; Thu, 30 Aug 2018 13:45:01 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:52786) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fvR06-0004WB-IS; Thu, 30 Aug 2018 13:44:58 -0400 Received: from [176.228.60.248] (port=2738 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fvR05-0006RI-HI; Thu, 30 Aug 2018 13:44:58 -0400 Date: Thu, 30 Aug 2018 20:44:41 +0300 Message-Id: <83in3r21h2.fsf@gnu.org> From: Eli Zaretskii To: Michael Albinus In-reply-to: <87h8jb7qcs.fsf@gmx.de> (message from Michael Albinus on Thu, 30 Aug 2018 18:48:19 +0200) Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> <87efemp0yz.fsf@runbox.com> <87pny1xiv5.fsf@gmx.de> <83in3t2lcl.fsf@gnu.org> <87lg8pxgs6.fsf@gmx.de> <83h8jd2jh6.fsf@gnu.org> <87d0u1xfek.fsf@gmx.de> <878t4oylcj.fsf@gmx.de> <874lfcyjpn.fsf@gmx.de> <834lfc37ji.fsf@gnu.org> <87zhx4wcsp.fsf@gmx.de> <83va7s0z7g.fsf@gnu.org> <87o9dkrncl.fsf@gmx.de> <83mut40xpp.fsf@gnu.org> <87h8jcvtt1.fsf@gmx.de> <87h8jb7qcs.fsf@gmx.de> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 32502 Cc: gazally@runbox.com, 32502@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: Michael Albinus > Cc: gazally@runbox.com, 32502@debbugs.gnu.org > Date: Thu, 30 Aug 2018 18:48:19 +0200 > > Appended is a first implementation. Comments? Looks good, thanks. > +If @var{thread} is the main thread, the signal is not propagated > +there. Instead, it is shown as message in the main thread. Maybe I'm missing something, but where's the code which shows this message? > @@ -863,7 +863,8 @@ DEFUN ("thread-signal", Fthread_signal, Sthread_signal, 3, 3, 0, > This acts like `signal', but arranges for the signal to be raised > in THREAD. If THREAD is the current thread, acts just like `signal'. > This will interrupt a blocked call to `mutex-lock', `condition-wait', > -or `thread-join' in the target thread. */) > +or `thread-join' in the target thread. > +Signals to the main thread are ignored quietly. */) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ That's not really accurate, is it? From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 30 15:29:59 2018 Received: (at 32502) by debbugs.gnu.org; 30 Aug 2018 19:30:00 +0000 Received: from localhost ([127.0.0.1]:39425 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvSdj-0000AG-MK for submit@debbugs.gnu.org; Thu, 30 Aug 2018 15:29:59 -0400 Received: from aibo.runbox.com ([91.220.196.211]:41678) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvSdh-0000A4-SD for 32502@debbugs.gnu.org; Thu, 30 Aug 2018 15:29:58 -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=DXtDl0f7nbAKIW3I/uPi5g42XErKgDjVrfK9qe56Je0=; b=BLmXq/Lr+8kpkITWKWAhEV3I/p AK6g9LT6m0VX6o3C8x8o7KLbNy4EpdiOi3HPIzBvNmbt1ttX9q8jn3UoXDYTimkCwzfhgBaWEAJgz 4bw4RT0VHhBDf60f0h6scr/7P1CrZEuDC2LX94Yo/bYONlkHGKNUQm18vL1kxTiANvPXheSELmuWV yn+ANS7f9s7n/qTYopTUssCbK/tZcyIzARVmfN0VLNZ+BCNZEjZt3VAEx9rUKmrtkrQtUbtPnbuv7 XUJ2Hph5M9+gj76Yxvx1Qmwns1h56MFWwcFsiQrg9V38dl1B/xJ475PQCnZQb6LYFDwly7t1Vk4Tc /Xs4ZrAw==; Received: from [10.9.9.210] (helo=mailfront10.runbox.com) by mailtransmit03.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1fvSdg-0001Vz-PF; Thu, 30 Aug 2018 21:29:56 +0200 Received: by mailfront10.runbox.com with esmtpsa (uid:179284 ) (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) id 1fvSdX-0000lM-0D; Thu, 30 Aug 2018 21:29:47 +0200 From: Gemini Lasswell To: Michael Albinus Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> <87efemp0yz.fsf@runbox.com> <87pny1xiv5.fsf@gmx.de> <83in3t2lcl.fsf@gnu.org> <87lg8pxgs6.fsf@gmx.de> <83h8jd2jh6.fsf@gnu.org> <87d0u1xfek.fsf@gmx.de> <878t4oylcj.fsf@gmx.de> <874lfcyjpn.fsf@gmx.de> <834lfc37ji.fsf@gnu.org> <87zhx4wcsp.fsf@gmx.de> <83va7s0z7g.fsf@gnu.org> <87o9dkrncl.fsf@gmx.de> <83mut40xpp.fsf@gnu.org> <87h8jcvtt1.fsf@gmx.de> <87h8jb7qcs.fsf@gmx.de> Date: Thu, 30 Aug 2018 12:29:44 -0700 In-Reply-To: <87h8jb7qcs.fsf@gmx.de> (Michael Albinus's message of "Thu, 30 Aug 2018 18:48:19 +0200") Message-ID: <87o9djwt3r.fsf@runbox.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 32502 Cc: 32502@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Michael Albinus writes: > Appended is a first implementation. Comments? I don't understand why this is so complicated. Why not just have the thread show a message, instead of having it send a signal which gets translated into an event that makes the main thread show a message? Also, if we eventually implement one of the proposals in emacs-devel to allow threads other than the main one to accept keyboard input, then there would be no guarantee that putting the event in the keyboard buffer would get it to the main thread. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 30 15:30:50 2018 Received: (at 32502) by debbugs.gnu.org; 30 Aug 2018 19:30:50 +0000 Received: from localhost ([127.0.0.1]:39430 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvSeX-0000DG-VV for submit@debbugs.gnu.org; Thu, 30 Aug 2018 15:30:50 -0400 Received: from mout.gmx.net ([212.227.17.20]:55865) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvSeW-0000D1-Lk for 32502@debbugs.gnu.org; Thu, 30 Aug 2018 15:30:49 -0400 Received: from detlef.gmx.de ([212.91.238.173]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LmrZY-1fPio80Y4S-00h7sk; Thu, 30 Aug 2018 21:30:40 +0200 From: Michael Albinus To: Eli Zaretskii Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> <87efemp0yz.fsf@runbox.com> <87pny1xiv5.fsf@gmx.de> <83in3t2lcl.fsf@gnu.org> <87lg8pxgs6.fsf@gmx.de> <83h8jd2jh6.fsf@gnu.org> <87d0u1xfek.fsf@gmx.de> <878t4oylcj.fsf@gmx.de> <874lfcyjpn.fsf@gmx.de> <834lfc37ji.fsf@gnu.org> <87zhx4wcsp.fsf@gmx.de> <83va7s0z7g.fsf@gnu.org> <87o9dkrncl.fsf@gmx.de> <83mut40xpp.fsf@gnu.org> <87h8jcvtt1.fsf@gmx.de> <87h8jb7qcs.fsf@gmx.de> <83in3r21h2.fsf@gnu.org> Date: Thu, 30 Aug 2018 21:30:35 +0200 Message-ID: <87sh2vps84.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:N/2qdS5XC18w3b9luY2DwFDKMHqoysfEN0CPOFryj/aeK105pv0 KbwNPPammgpKKMoRWckzlmKU1mfkOCkUhnvUeivbPNl12MlZlUjMsTprflJEP268KlRALxV 5/gwspDgCiu5OsdszQHHbzvNQUu46BABilgCBcow2c5+g/ivvwwfTyKaNgoC5e8pSP3a6Jt yn5aL1dddGh4K8BJR8csQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:YkN+GtqgE+s=:QCKhncECO9Yk4dX17TBtEC X7IU8F+opjocw8+7aYZOTn5977QP5rdbUoLqNd9Lj/OtefIucgzGd79OqgI9N3LHIvrlnlJvW QAxIbZOVewt/45B+FJoM0xJ0vcuF/xCh6CugPNeMj5VVs3Wdvtm3UFIIexVOM+XfajjV2Wmkt tWDeXK9dPcbheExphi4Xq5z+YxKviq+ix9AmJHjgZb8rEg/SUAzqdYgrX+JxOpfAEy776rsTv DzyxYG6vKMWQExABW1LarUENCplqmmo0tLe9g82Hqat8N5abhlQKyIbzRwhjSpyx2aDEWYKkY 6cBOHd17522o2D1CQIbbpezvrinw/k825ZsJCRwQ9NqOMz/lVnd+3FL8Ul3/AbcTdVD0LQJLe UjIWCA+Hj0ifxsopuF2YTnQaRD5J7RID5O2jfvplVhqdHYfUGWS6BE9TEdI/AG8Ch4dJhw8pq m49beVNwxRCP6seEzUceXgv0FEAJjgNdkysfq7+bTYQ1n3m4NtyXa5TUviNld/ui6YskbPME5 lr4S4/cLzwX/p8C/hhIw9utFVz6YSmjpMnh1vaiTF+2w9OPgPKT2BKpON6+rxxId8kZE2h5CI AVjr3u9m9GHkJk4pDR3vacBWKYbWgMxUCbAaW0EniUVa84/uTsYHLGmvjZA5wKjBWdLuF0z1I thhda2H3uCre4sXR+lP8upQFthpr57Y5qT+oz+uO7zuCbtOrtphHgjeGac7tZHRbODTpEnKo/ Iyl2x+FtbuxtYhIB8W4uASLSMvBs8/uXsdOR4GZvzy/2tplJywiCnqrnAxFw0l+I86XmNUrVT exZHSj4 X-Spam-Score: 4.9 (++++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii writes: >> +If @var{thread} is the main thread, the signal is not propagated >> +there. Instead, it is shown as message in the main thread. > > Maybe I'm missing something, but where's the code which shows this > message? [...] Content analysis details: (4.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (michael.albinus[at]gmx.de) 2.5 RCVD_IN_SORBS_HTTP RBL: SORBS: sender is open HTTP proxy server [212.91.238.173 listed in dnsbl.sorbs.net] 2.4 RCVD_IN_SORBS_SOCKS RBL: SORBS: sender is open SOCKS proxy server -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [212.227.17.20 listed in list.dnswl.org] X-Debbugs-Envelope-To: 32502 Cc: gazally@runbox.com, 32502@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 3.9 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii writes: >> +If @var{thread} is the main thread, the signal is not propagated >> +there. Instead, it is shown as message in the main thread. > > Maybe I'm missing something, but where's the code which shows this > message? [...] Content analysis details: (3.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [212.227.17.20 listed in list.dnswl.org] 2.5 RCVD_IN_SORBS_HTTP RBL: SORBS: sender is open HTTP proxy server [212.91.238.173 listed in dnsbl.sorbs.net] 2.4 RCVD_IN_SORBS_SOCKS RBL: SORBS: sender is open SOCKS proxy server -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (michael.albinus[at]gmx.de) -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager Eli Zaretskii writes: >> +If @var{thread} is the main thread, the signal is not propagated >> +there. Instead, it is shown as message in the main thread. > > Maybe I'm missing something, but where's the code which shows this > message? thread-handle-event of thread.el. >> @@ -863,7 +863,8 @@ DEFUN ("thread-signal", Fthread_signal, Sthread_signal, 3, 3, 0, >> This acts like `signal', but arranges for the signal to be raised >> in THREAD. If THREAD is the current thread, acts just like `signal'. >> This will interrupt a blocked call to `mutex-lock', `condition-wait', >> -or `thread-join' in the target thread. */) >> +or `thread-join' in the target thread. >> +Signals to the main thread are ignored quietly. */) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > That's not really accurate, is it? Oh, this is from my first attempt. Fixed. I've committed this to the master. Let's see how it goes. Gemini, I've stolen the frame of your thread.el from the scratch/list-threads branch. You will merge your code there, I guess. I'm a little bit undecided, whether thread events shall be restricted to signaling the main thread with error messages. Could be used for other purposes as well. Let's see. Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 30 15:37:41 2018 Received: (at 32502) by debbugs.gnu.org; 30 Aug 2018 19:37:42 +0000 Received: from localhost ([127.0.0.1]:39435 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvSlB-0000NI-NL for submit@debbugs.gnu.org; Thu, 30 Aug 2018 15:37:41 -0400 Received: from mout.gmx.net ([212.227.15.19]:44937) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvSl9-0000N3-P5 for 32502@debbugs.gnu.org; Thu, 30 Aug 2018 15:37:40 -0400 Received: from detlef.gmx.de ([212.91.238.173]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MYfX0-1gQn6X2vAo-00VNFs; Thu, 30 Aug 2018 21:37:31 +0200 From: Michael Albinus To: Gemini Lasswell Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> <87efemp0yz.fsf@runbox.com> <87pny1xiv5.fsf@gmx.de> <83in3t2lcl.fsf@gnu.org> <87lg8pxgs6.fsf@gmx.de> <83h8jd2jh6.fsf@gnu.org> <87d0u1xfek.fsf@gmx.de> <878t4oylcj.fsf@gmx.de> <874lfcyjpn.fsf@gmx.de> <834lfc37ji.fsf@gnu.org> <87zhx4wcsp.fsf@gmx.de> <83va7s0z7g.fsf@gnu.org> <87o9dkrncl.fsf@gmx.de> <83mut40xpp.fsf@gnu.org> <87h8jcvtt1.fsf@gmx.de> <87h8jb7qcs.fsf@gmx.de> <87o9djwt3r.fsf@runbox.com> Date: Thu, 30 Aug 2018 21:37:29 +0200 In-Reply-To: <87o9djwt3r.fsf@runbox.com> (Gemini Lasswell's message of "Thu, 30 Aug 2018 12:29:44 -0700") Message-ID: <87o9djprwm.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:PJLOzE+5zY74E6AOyM769j0dVEZcwezPofrawE1DPqMwI49L8k2 mJwgZo+Meaia+g5qcY2IJhXiIPO++ZUC1rh3Fy6hH0b+dy0vpj6su/J1RHFMBCNdo17cA1Y ECHF1MM9VDdk++PwoqKN7FrSFCBZfXet+bQbpow9hzutj7PJX6j/UhN8mFls3S1zyKgg91O j/TYW5Q0+jKyXjBQqmxOQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:NTt8t8fy6eY=:794NYcJkolxtk39+4Dk4Nj IwChbByAf0b/GHkfchObZ/COLYYAAsTQJpQT5F6MqG5G2yK1yYlHtgKTdhfVzFJ06UH7OD4Ba JOppLi13eg6mXigfKZyFFrKM2QVQYQaR+p+fSlRc+KYOkBCRBfIG6iYjd6LQDzGlREuT8lrxT Ab54IPaBwao8jwfBXoHrC+McFJdShg1zwfPNCeO8Vfm6saFhCxpei2h53Og6W6BhpGEO8ySxz 8q09Lq9LgV3qDdtlw4fa7nKNFv5R8eW6QYxrUSazDpEOfj/Jcx+EGlGYf/0xCjoxbZoPxGZ0g WajTe+LH4sDJOOwg6pc3kiuYyKqpePqTffS7w30VkuAA3BHyNhmRoU0W+6zyWT1vGQDySe9hn peVzIA4Mgbij+Z7TiTsZDyuDYoluKmuxK2cTdou5rkHLU6O+UvBpTo+4XP6zVPH2OV4OATPr7 itn/YDi79rsLmPiMPyP8a1mOreZIKzBnnQGwPb4QzEM7b3tnR8P7QToCaROL7ostWQstN8Rgh uC3eWApY9p8g3vOk2HtbeF9+Tv+SwXltnUsdttbNWtVPGt5onXE2sI3St6EbdNZ9Z6SB+vJ6U V0UHmSDiSazfPS6W9hJJGgxxRRD0JSfn7oDuhyEwIQU+qedKUhiSdmVtI1j/+rpBOH0E/goD/ BxYLSe37BQjPSPSwH1JT3B+ZO5r43PfnImLdooNVZIU6RnXJtoz0fz2n2yth3LWJU5xO9nWYM sQbNodCQrrOgWqrl34An0+egKo2N4qCL6bRJ/zzW0wJuE9zUYIzkS8A0LmoSPlc70CGtnvqqC dbD2H5W X-Spam-Score: 4.2 (++++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Gemini Lasswell writes: > I don't understand why this is so complicated. Why not just have the > thread show a message, instead of having it send a signal which gets > translated into an event that makes the main thread show a message? [...] Content analysis details: (4.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.5 RCVD_IN_SORBS_HTTP RBL: SORBS: sender is open HTTP proxy server [212.91.238.173 listed in dnsbl.sorbs.net] 2.4 RCVD_IN_SORBS_SOCKS RBL: SORBS: sender is open SOCKS proxy server -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (michael.albinus[at]gmx.de) -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.15.19 listed in list.dnswl.org] X-Debbugs-Envelope-To: 32502 Cc: 32502@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 3.2 (+++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Gemini Lasswell writes: > I don't understand why this is so complicated. Why not just have the > thread show a message, instead of having it send a signal which gets > translated into an event that makes the main thread show a message? [...] Content analysis details: (3.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [212.227.15.19 listed in list.dnswl.org] 2.5 RCVD_IN_SORBS_HTTP RBL: SORBS: sender is open HTTP proxy server [212.91.238.173 listed in dnsbl.sorbs.net] 2.4 RCVD_IN_SORBS_SOCKS RBL: SORBS: sender is open SOCKS proxy server -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (michael.albinus[at]gmx.de) -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager Gemini Lasswell writes: > I don't understand why this is so complicated. Why not just have the > thread show a message, instead of having it send a signal which gets > translated into an event that makes the main thread show a message? With thread-handle-event, the main thread could decide to react on the signal/event. > Also, if we eventually implement one of the proposals in emacs-devel to > allow threads other than the main one to accept keyboard input, then > there would be no guarantee that putting the event in the keyboard > buffer would get it to the main thread. We'll see. The event-based implementation was easy to do; it would also be easy to change. Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 31 02:52:43 2018 Received: (at 32502) by debbugs.gnu.org; 31 Aug 2018 06:52:43 +0000 Received: from localhost ([127.0.0.1]:39692 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvdIR-0006XO-L8 for submit@debbugs.gnu.org; Fri, 31 Aug 2018 02:52:43 -0400 Received: from eggs.gnu.org ([208.118.235.92]:48666) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvdIP-0006XB-P8 for 32502@debbugs.gnu.org; Fri, 31 Aug 2018 02:52:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fvdIH-0001tO-EH for 32502@debbugs.gnu.org; Fri, 31 Aug 2018 02:52:36 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39495) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fvdIH-0001tD-9a; Fri, 31 Aug 2018 02:52:33 -0400 Received: from [176.228.60.248] (port=3579 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fvdIG-0005hF-TL; Fri, 31 Aug 2018 02:52:33 -0400 Date: Fri, 31 Aug 2018 09:52:19 +0300 Message-Id: <83ftyv110c.fsf@gnu.org> From: Eli Zaretskii To: Gemini Lasswell In-reply-to: <87o9djwt3r.fsf@runbox.com> (message from Gemini Lasswell on Thu, 30 Aug 2018 12:29:44 -0700) Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> <87efemp0yz.fsf@runbox.com> <87pny1xiv5.fsf@gmx.de> <83in3t2lcl.fsf@gnu.org> <87lg8pxgs6.fsf@gmx.de> <83h8jd2jh6.fsf@gnu.org> <87d0u1xfek.fsf@gmx.de> <878t4oylcj.fsf@gmx.de> <874lfcyjpn.fsf@gmx.de> <834lfc37ji.fsf@gnu.org> <87zhx4wcsp.fsf@gmx.de> <83va7s0z7g.fsf@gnu.org> <87o9dkrncl.fsf@gmx.de> <83mut40xpp.fsf@gnu.org> <87h8jcvtt1.fsf@gmx.de> <87h8jb7qcs.fsf@gmx.de> <87o9djwt3r.fsf@runbox.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 32502 Cc: 32502@debbugs.gnu.org, michael.albinus@gmx.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: Gemini Lasswell > Cc: Eli Zaretskii , 32502@debbugs.gnu.org > Date: Thu, 30 Aug 2018 12:29:44 -0700 > > I don't understand why this is so complicated. Why not just have the > thread show a message, instead of having it send a signal which gets > translated into an event that makes the main thread show a message? Because the echo area could be showing something important from the main (or some other) thread, e.g. if the user typed "C-x C-f", but didn't yet finish responding to the request for the file name. Displaying something from another thread will wipe out that interaction's text. By submitting an event to the main thread, we make sure these two interactions will be serialized. > Also, if we eventually implement one of the proposals in emacs-devel to > allow threads other than the main one to accept keyboard input, then > there would be no guarantee that putting the event in the keyboard > buffer would get it to the main thread. I don't think it matters, because it will get to the thread which is reading input events, and that thread will then act on the event. But if it turns out it does matter, we can always tag each even with its target thread or something, and modify the queue handling to only act on events whose target is the current thread. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 31 11:08:16 2018 Received: (at 32502) by debbugs.gnu.org; 31 Aug 2018 15:08:16 +0000 Received: from localhost ([127.0.0.1]:40774 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvl20-00066y-KX for submit@debbugs.gnu.org; Fri, 31 Aug 2018 11:08:16 -0400 Received: from aibo.runbox.com ([91.220.196.211]:35846) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvl1y-00066p-5G for 32502@debbugs.gnu.org; Fri, 31 Aug 2018 11:08:14 -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=Tq0bf7sq/AlrphYoDjBdKT8YTcgC3dO4rKWvwpZ81Zk=; b=FtV1m/TEGwGzQoRo9s4F6FAZOF KJj+HibKqndkt8C/KEiCY1zlMvhE79vAbAyDLEVg1LoOQZQbd4ctZF0ipcfF/ik2g1OptsUwamplu BwTpoGKBHKMDGeTI2Jobm2/8G1hT344BA4RztRc3u2PVX5aVSUENLQxRDyp3QGpcAdbRws8wFZUTy kJBN+Fa/ZG2zWuy72Xh6TaNdSANyUs6HHUU+T84i62uaR6zouyJQxk4PcVw3urJjGCf/LFs2sVuVw Zmx8HnsXVBFzJligVfqfD/0vWdgs7s5MVYwjxHGLYZA2Wiea52tRL21zI7iF0/U3aMtYCI9vG2PGX GS9pghcg==; Received: from [10.9.9.210] (helo=mailfront10.runbox.com) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1fvl1w-0005ie-NG; Fri, 31 Aug 2018 17:08:12 +0200 Received: by mailfront10.runbox.com with esmtpsa (uid:179284 ) (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) id 1fvl1i-0001wn-4S; Fri, 31 Aug 2018 17:07:58 +0200 From: Gemini Lasswell To: Eli Zaretskii Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> <87efemp0yz.fsf@runbox.com> <87pny1xiv5.fsf@gmx.de> <83in3t2lcl.fsf@gnu.org> <87lg8pxgs6.fsf@gmx.de> <83h8jd2jh6.fsf@gnu.org> <87d0u1xfek.fsf@gmx.de> <878t4oylcj.fsf@gmx.de> <874lfcyjpn.fsf@gmx.de> <834lfc37ji.fsf@gnu.org> <87zhx4wcsp.fsf@gmx.de> <83va7s0z7g.fsf@gnu.org> <87o9dkrncl.fsf@gmx.de> <83mut40xpp.fsf@gnu.org> <87h8jcvtt1.fsf@gmx.de> <87h8jb7qcs.fsf@gmx.de> <87o9djwt3r.fsf@runbox.com> <83ftyv110c.fsf@gnu.org> Date: Fri, 31 Aug 2018 08:07:55 -0700 In-Reply-To: <83ftyv110c.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 31 Aug 2018 09:52:19 +0300") Message-ID: <87bm9iwp4k.fsf@runbox.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 32502 Cc: 32502@debbugs.gnu.org, michael.albinus@gmx.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Eli Zaretskii writes: >> From: Gemini Lasswell >> >> I don't understand why this is so complicated. Why not just have the >> thread show a message, instead of having it send a signal which gets >> translated into an event that makes the main thread show a message? > > Because the echo area could be showing something important from the > main (or some other) thread, e.g. if the user typed "C-x C-f", but > didn't yet finish responding to the request for the file name. > Displaying something from another thread will wipe out that > interaction's text. In the feature/tramp-thread-safe branch, main thread prompts already get wiped out by messages from other threads, even in the absence of errors. For example, if you start an asynchronous find-file and type M-x before it finishes, the M-x prompt will be overwritten by messages from Tramp and won't reappear after the find-file finishes, until you type something. From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 31 13:45:56 2018 Received: (at 32502) by debbugs.gnu.org; 31 Aug 2018 17:45:56 +0000 Received: from localhost ([127.0.0.1]:40931 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvnUa-0003iz-Ee for submit@debbugs.gnu.org; Fri, 31 Aug 2018 13:45:56 -0400 Received: from eggs.gnu.org ([208.118.235.92]:46747) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fvnUY-0003ik-ML for 32502@debbugs.gnu.org; Fri, 31 Aug 2018 13:45:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fvnUR-0007MY-Dv for 32502@debbugs.gnu.org; Fri, 31 Aug 2018 13:45:49 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05 autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37932) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fvnUL-0007HA-IL; Fri, 31 Aug 2018 13:45:41 -0400 Received: from [176.228.60.248] (port=4557 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fvnUL-00085o-4b; Fri, 31 Aug 2018 13:45:41 -0400 Date: Fri, 31 Aug 2018 20:45:27 +0300 Message-Id: <838t4m2zwo.fsf@gnu.org> From: Eli Zaretskii To: Gemini Lasswell In-reply-to: <87bm9iwp4k.fsf@runbox.com> (message from Gemini Lasswell on Fri, 31 Aug 2018 08:07:55 -0700) Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> <87efemp0yz.fsf@runbox.com> <87pny1xiv5.fsf@gmx.de> <83in3t2lcl.fsf@gnu.org> <87lg8pxgs6.fsf@gmx.de> <83h8jd2jh6.fsf@gnu.org> <87d0u1xfek.fsf@gmx.de> <878t4oylcj.fsf@gmx.de> <874lfcyjpn.fsf@gmx.de> <834lfc37ji.fsf@gnu.org> <87zhx4wcsp.fsf@gmx.de> <83va7s0z7g.fsf@gnu.org> <87o9dkrncl.fsf@gmx.de> <83mut40xpp.fsf@gnu.org> <87h8jcvtt1.fsf@gmx.de> <87h8jb7qcs.fsf@gmx.de> <87o9djwt3r.fsf@runbox.com> <83ftyv110c.fsf@gnu.org> <87bm9iwp4k.fsf@runbox.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: 32502 Cc: 32502@debbugs.gnu.org, michael.albinus@gmx.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -6.0 (------) > From: Gemini Lasswell > Cc: 32502@debbugs.gnu.org, michael.albinus@gmx.de > Date: Fri, 31 Aug 2018 08:07:55 -0700 > > > Because the echo area could be showing something important from the > > main (or some other) thread, e.g. if the user typed "C-x C-f", but > > didn't yet finish responding to the request for the file name. > > Displaying something from another thread will wipe out that > > interaction's text. > > In the feature/tramp-thread-safe branch, main thread prompts already get > wiped out by messages from other threads, even in the absence of errors. Which is why we are having the discussion on emacs-devel trying to figure out how to avoid that. Displaying an error message is a simpler problem, because it doesn't require any response. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 02 13:58:15 2018 Received: (at 32502) by debbugs.gnu.org; 2 Sep 2018 17:58:15 +0000 Received: from localhost ([127.0.0.1]:43276 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fwWdb-0002dB-10 for submit@debbugs.gnu.org; Sun, 02 Sep 2018 13:58:15 -0400 Received: from mout.gmx.net ([212.227.15.19]:56245) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fwWdZ-0002cz-DH for 32502@debbugs.gnu.org; Sun, 02 Sep 2018 13:58:13 -0400 Received: from detlef.gmx.de ([212.86.54.210]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MgL1q-1gI3fH3WKM-00NipW; Sun, 02 Sep 2018 19:58:05 +0200 From: Michael Albinus To: gazally@runbox.com Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83o9dub5nx.fsf@gnu.org> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> <87efemp0yz.fsf@runbox.com> <87pny1xiv5.fsf@gmx.de> <83in3t2lcl.fsf@gnu.org> <87lg8pxgs6.fsf@gmx.de> <83h8jd2jh6.fsf@gnu.org> <87d0u1xfek.fsf@gmx.de> <878t4oylcj.fsf@gmx.de> <874lfcyjpn.fsf@gmx.de> <834lfc37ji.fsf@gnu.org> <87zhx4wcsp.fsf@gmx.de> <83va7s0z7g.fsf@gnu.org> <87o9dkrncl.fsf@gmx.de> <83mut40xpp.fsf@gnu.org> <87h8jcvtt1.fsf@gmx.de> <87h8jb7qcs.fsf@gmx.de> <83in3r21h2.fsf@gnu.org> <87sh2vps84.fsf@gmx.de> Date: Sun, 02 Sep 2018 19:58:04 +0200 In-Reply-To: <87sh2vps84.fsf@gmx.de> (Michael Albinus's message of "Thu, 30 Aug 2018 21:30:35 +0200") Message-ID: <87va7nok7n.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:/Pp8N6Uiusjnb3L5OJlXAK7QvUQdyDTo32ctbG8uTjecgnpbubH 3pyCtaKUqKRM/PZSgJP4KqMqAX0xrkuAfC9yAam+KW6ToFQRfgcLTtDyjeLiwipiIWiPsaK 6dXelV50O5yLvbGQS+JVmxhw2fubPavnX3Yab3WzmtBj3E6IhaMYqgoQi62uHQ/L+TLSaJk 0sIMXpMMgd10v4lDJaZEg== X-UI-Out-Filterresults: notjunk:1;V01:K0:Ob2JTLAA3Ck=:TDN8GZg4Xp8AAmLnF+tMeO fVORp0ETlccdCbFsw+mc38Q96KZXE49+1sA0veaR/a4eUOZ7z3LNqBKffTM7AcfOMuj1kwPHL WGZDUIxfdFqbSn0w4DMzQU+ilX93np3BoIWPFxKul2NDbp6fUSE095Xd4JjJ0pdtRfBx22Imm KuSALmLWxxmescgUESOxFfldeblX2ACpCIRqHCHA/r5tvOVCuOXThLNx0q50QDZnUW2JLA1Yq qwx4LQcj8+2JsproyGydD+8TiEm7X7vNxIQRnqbtB0BgBFM4c9nTblEd2A5HMUuJm/gQwVcFX WVeoPEOXz/8g8VKc1JYBAfw+tr3b+HVQgBKTtqsPQLY0cJtMKw2Xv9OLhSeBNhiZ8oTgRwQnK 1fqJeBgaU0tqHaHhKbbt5nrHXFRKYRQ9p/lBYnakXz3xzWLEFEOrZbdYImG9pTHfeVtjvzCgd ojXV3Z91+vzX+DZQI6iYWLMVRd11+M4Mrlu/SUyr8AWpMkuT9wDaPByDtL4YXaz7i30a6oj1w 8fhAe8xLDlxe7nwZOsThJRDqOdRal3XsoPOUok/zCIVlRcRJxdGN8naD8eWQzigadRY7f5V0b 8kpXYl99fwQ8H3PSGcqEt/vC3Pv4zfhUVzrJdBdYmWvRPwWoOTDhpEm7Y6RuiyDatRukdO5sF 7NqFoKVvhPLnSchChZXAN0/zRiYz8PM4GaZzubSsErCURJe3TL1cpfMtivM87Z1TQx4wlRl9r 3rzUoQsYEohUqOf0lo369ElXiw3oTf9uKkGlBwMaY+nnZ12R4zyfcFX/f2SDOpl0LNGoaEZmk SXkB8Ju X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 32502 Cc: 32502@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Michael Albinus writes: Hi Gemini, > I've committed this to the master. Let's see how it goes. Does this work for you? In this case, I'd like to close the bug. Or do you need something else? Best regards, Michael. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 02 16:04:04 2018 Received: (at 32502) by debbugs.gnu.org; 2 Sep 2018 20:04:04 +0000 Received: from localhost ([127.0.0.1]:43345 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fwYbM-0007sE-4t for submit@debbugs.gnu.org; Sun, 02 Sep 2018 16:04:04 -0400 Received: from aibo.runbox.com ([91.220.196.211]:60434) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fwYbK-0007ro-8S for 32502@debbugs.gnu.org; Sun, 02 Sep 2018 16:04:03 -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=MjZyK9DCte6MmWRu6ohX56q/Rpd2TLYvuhKnxcZzcFs=; b=RbCoIS1psQyXyHbwYZgGxMz/np k3RA1uiI+kjY38pJBGZXk1fe0sMgi1fIYpvBaD6yeClEGFQW+cNu8dKaOhHs3luSpG4hCLvtYd8uf coC82HUGV0Z3WRYQwH/jlq0b+bRAzdB81DbOfVdmkuHdJRadrbb96mLh5hBxWAWI7yHukdaYLQwK2 6veQgJp3QzEAZJ9Qv2FgdDwT2C0p9ni0JnJwcCNK+641zXwC3LMa1n32ndFzdN2iI5PB2IELo5b2t wCUK1xPsWzGR1ypxM6KeGLIuk7EymspgZ/st0U5m3MjZRHNL5cHWot2vYsBvLFK5n0HnWunYih4Cy BOS0O4ng==; Received: from [10.9.9.210] (helo=mailfront10.runbox.com) by mailtransmit02.runbox with esmtp (Exim 4.86_2) (envelope-from ) id 1fwYbH-0005fF-UV; Sun, 02 Sep 2018 22:04:00 +0200 Received: by mailfront10.runbox.com with esmtpsa (uid:179284 ) (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) id 1fwYb9-0004np-SF; Sun, 02 Sep 2018 22:03:52 +0200 From: Gemini Lasswell To: Michael Albinus Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <83muteb4nb.fsf@gnu.org> <87o9dqbtv5.fsf@gmx.de> <87efemp0yz.fsf@runbox.com> <87pny1xiv5.fsf@gmx.de> <83in3t2lcl.fsf@gnu.org> <87lg8pxgs6.fsf@gmx.de> <83h8jd2jh6.fsf@gnu.org> <87d0u1xfek.fsf@gmx.de> <878t4oylcj.fsf@gmx.de> <874lfcyjpn.fsf@gmx.de> <834lfc37ji.fsf@gnu.org> <87zhx4wcsp.fsf@gmx.de> <83va7s0z7g.fsf@gnu.org> <87o9dkrncl.fsf@gmx.de> <83mut40xpp.fsf@gnu.org> <87h8jcvtt1.fsf@gmx.de> <87h8jb7qcs.fsf@gmx.de> <83in3r21h2.fsf@gnu.org> <87sh2vps84.fsf@gmx.de> <87va7nok7n.fsf@gmx.de> Date: Sun, 02 Sep 2018 13:03:49 -0700 In-Reply-To: <87va7nok7n.fsf@gmx.de> (Michael Albinus's message of "Sun, 02 Sep 2018 19:58:04 +0200") Message-ID: <878t4jvf8a.fsf@runbox.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 32502 Cc: 32502@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Michael Albinus writes: >> I've committed this to the master. Let's see how it goes. > > Does this work for you? In this case, I'd like to close the bug. Or do > you need something else? Hi Michael, I tried this in the thread-safe-tramp branch and it fixes the problem. Thanks, Gemini From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 02 16:50:40 2018 Received: (at 32502-done) by debbugs.gnu.org; 2 Sep 2018 20:50:40 +0000 Received: from localhost ([127.0.0.1]:43394 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fwZKS-0000aN-2C for submit@debbugs.gnu.org; Sun, 02 Sep 2018 16:50:40 -0400 Received: from mout.gmx.net ([212.227.15.19]:52907) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fwZKO-0000a8-F1 for 32502-done@debbugs.gnu.org; Sun, 02 Sep 2018 16:50:37 -0400 Received: from detlef.gmx.de ([212.86.54.210]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MEFIm-1g7bx63td2-00FSoI; Sun, 02 Sep 2018 22:50:29 +0200 From: Michael Albinus To: Gemini Lasswell Subject: Re: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs References: <87mutep8ll.fsf@runbox.com> <87o9dqbtv5.fsf@gmx.de> <87efemp0yz.fsf@runbox.com> <87pny1xiv5.fsf@gmx.de> <83in3t2lcl.fsf@gnu.org> <87lg8pxgs6.fsf@gmx.de> <83h8jd2jh6.fsf@gnu.org> <87d0u1xfek.fsf@gmx.de> <878t4oylcj.fsf@gmx.de> <874lfcyjpn.fsf@gmx.de> <834lfc37ji.fsf@gnu.org> <87zhx4wcsp.fsf@gmx.de> <83va7s0z7g.fsf@gnu.org> <87o9dkrncl.fsf@gmx.de> <83mut40xpp.fsf@gnu.org> <87h8jcvtt1.fsf@gmx.de> <87h8jb7qcs.fsf@gmx.de> <83in3r21h2.fsf@gnu.org> <87sh2vps84.fsf@gmx.de> <87va7nok7n.fsf@gmx.de> <878t4jvf8a.fsf@runbox.com> Date: Sun, 02 Sep 2018 22:50:25 +0200 In-Reply-To: <878t4jvf8a.fsf@runbox.com> (Gemini Lasswell's message of "Sun, 02 Sep 2018 13:03:49 -0700") Message-ID: <87r2iboc8e.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:r7Vljui0wxWI3gMnRO2nE+NZ1g4oXAfGe8VAkfR+EiHt03B5vC6 B0txBG5xVk8GNY5V4wwY4OV5J7RvgE+gp45dLS1A4a+YgCCciMwLGLDybDo7wJmz8RrrdT8 GwiGqn4k23vZrBkUE53RJfywgKaOpiZmDNPJNJKf7vafckYULsHT7qgt023K0slpyl6Aef6 V8y58iGrb2y3j1kaDwYLQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:8ubdJPPidBE=:DsT6p5ieCA0DJ5piuqwIPe xf0iXb2gka7ZANtoGM+vpWJwnWzBfMUrg2uaHi8TweBoT8v04I7GOwbwTfLsJG9lktTgFZx3B P6c2pUc4S5nqCR+bhQAOgeLPGHhXF/bzK0nxtdbI8qPEQBrX/JXZHhbEBEUbd+cZglDCGiiT1 UylVLckfcJycd8sseW8rjN3XjSRiarGruYIWLo2s1clHMl8P3JPyDRY2HRH+JHjG/YNKO9rHW hhda94EYZnnpF07SGYTdoi1CzuOzMC9ylw4Dg2EZyIbT2SuByOdGvRLM9Kr1jXeosbrWVwTyy ucmmk7fp9ewyVCcC4ToHIzxWOsLUS3vo0Fd1iy2t0uzLN49X/B13N/K+iiySTUGXc8FwrqdCj 8TrJMg+phdgOt0HsSCYVD0j5g8XfRQDPc8HDfNUG4eidtFlW2+y1AriuKhJa28RA5V6f4otA8 A81v6aLM78QC/JVFd69dtKYNkcVFmYNKV9sEF7oegBI5zzfVo4BGnisIVFFy5/iUiodnNJ+mz SB57F2sqb6U7jR2hAqQJn/V00tsyxc7cQP3qnMIvDfpry9kdPtBJhtdcyfKQjY5Na+dFhjj0L 7YD7AAq/E2vXHmbw9iy8yS9aYtH869NcaRstWQD3VT9mIUzkzoLZgO6dE5pC2ypxJoGLcVw22 F1zvF6pCOR+MrTGC+kiN1AdZ2StHpOPoTg8wWgjCFdAy4RIuHL+aleuhJp4M0yvQ18jXMgD0L 2nsmeREMpYDd4OiCEYJndpJS0pQS80mUU/UWj7KVUP2FA+mKnHXtZ4Cx9yzYfz3P8yzSITa08 oBjh7xb X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 32502-done Cc: 32502-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Version: 27.1 Gemini Lasswell writes: > Hi Michael, Hi Gemini, > I tried this in the thread-safe-tramp branch and it fixes the problem. Thanks, I'm closing the bug. > Thanks, > Gemini Best regards, Michael. From unknown Fri Sep 19 21:16:31 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 01 Oct 2018 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator