GNU bug report logs - #32502
27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs

Previous Next

Full log

Message #29 received at 32502 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gazally <at> runbox.com, 32502 <at> debbugs.gnu.org
Subject: Re: bug#32502: 27.0.50; Tramp;
 C-g during asynchronous remote find-file kills Emacs
Date: Sat, 25 Aug 2018 17:52:34 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Michael Albinus <michael.albinus <at> gmx.de>
>> Cc: gazally <at> runbox.com,  32502 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.