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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 75056@debbugs.gnu.org
> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Date: Fri, 27 Dec 2024 07:04:54 +0100
> 
> I can reproduce what you describe, I think, but I must admit that I'm a
> bit at a loss at the moment. Something similar happens BTW if the server
> is a GUI Emacs. Pretty weird.
> 
> And then I found this in admin/notes/multi-tty, under known problems:
> 
>         * The single-kboard mode.
> 
> 	  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.  To unfreeze your session, switch to that
> 	  display and complete the recursive edit, for example by
> 	  pressing C-] ('abort-recursive-edit').
> 
> 	  I am sorry to say that currently there is no way to break
> 	  out of this "single-kboard mode" from a frozen display.  If
> 	  you are unable to switch to the display that locks the
> 	  others (for example because it is on a remote computer),
> 	  then you can use emacsclient to break out of all recursive
> 	  editing sessions:
> 
> 		emacsclient -e '(top-level)'
> 
> 	  Note that this (perhaps) unintuitive behavior is by design.
> 	  Single-kboard mode is required because of an intrinsic Emacs
> 	  limitation that is very hard to eliminate.  (This limitation
> 	  is related to the single-threaded nature of Emacs.)
> 
> 	  I plan to implement better user notification and support for
> 	  breaking out of single-kboard mode from locked displays.
> 
> Also see the long list of things to do in the same file, which makes me
> a bit wary.

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?

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.