[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kill

From: Michael Albinus
Subject: bug#32502: 27.0.50; Tramp; C-g during asynchronous remote find-file kills Emacs
Date: Sat, 25 Aug 2018 17:52:34 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: Michael Albinus <address@hidden>
>> Cc: address@hidden,  address@hidden
>> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]