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

[Gerd Möllmann]

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.

Not an explanation of course, but it smells a lot like what's happening.
What the real reason behind all this is in the code, and what would need
to be fixed, I can't figure out from notes/multi-tty. Maybe come
combination of open things mentioned there, no idea.

>
> IOW, I don't yet have a clear picture of what happens, although the
> limitations you found in that admin file are known to me.  AFAIK, the
> single-kboard situation is still with us, search keyboard.c for
> "single_kboard".
>
>> @Eli: I think we should invoke a multi-tty expert who can tell if what
>> we see here can be kind of expected with the current state of multi-tty or
>> not. And maybe can tell how up-to-date admin/notes/multi-tty is in the
>> first place.
>
> We don't have such an expert on board, sadly, not for a long while.
> We are on our own.

That's indeed more than suboptimal :-(.