Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> > #3 0x000000000057115b in Fsignal (error_symbol=<optimized out>,
>> > data=<optimized out>) at eval.c:1582
>> > #4 0x00000000005d5555 in post_acquire_global_lock
>> > (self=self@entry=0xc19320 <main_thread>) 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.