bug#75056: 31.0.50; tty-child-frames with server / multiple clients possible hangs

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: lenbok@gmail.com,  75056@debbugs.gnu.org
>> Date: Fri, 27 Dec 2024 09:46:48 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Can you explain how the above limitation causes the problem reported
>> > in this bug?  That is, how do child frames trigger the bug?  Because
>> > "normal" frames don't, AFAIU, right?  That is, one could have two or
>> > more client TTY frames on several displays in the same Emacs session,
>> > without having any of them stop being responsive, right?  Also, what
>> > is the role of vertico-posframe in this scenario?
>> 
>> The hint I see is here
>> 
>> >> 	  If your multi-tty Emacs session seems to be frozen, you
>> >> 	  probably have a recursive editing session or a pending
>> >> 	  minibuffer prompt (which is a kind of recursive editing) on
>> >> 	  another display.
>> 
>> Emacs in our case is kind of frozen, and Vertico is a minibuffer
>> interaction, where Posframe simply displays the minibuffer differently,
>> in a child frame.
>
> Yes, but where is that recursive editing in this scenario?

We're switching frames while being in the minibuffer in the other frame.

> I guess I'd love to see a C backtrace from that situation.

Too difficult for me. Emacs is not frozen in the sense that it is
completely stuck somewhere. For example, C-x C-c apparently always
works. C-g seems to work sometimes too, sometimes not. It's more like
the keyboard input doesn't land where it is supposed to. Or something
like that.