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

[Eli Zaretskii <eliz@gnu.org>]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: lenbok@gmail.com,  75056@debbugs.gnu.org
> Date: Fri, 27 Dec 2024 13:47:09 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Then why is this a bug?
> >
> > When a frame is in a minibuffer, it means Emacs asks the user about
> > something, and in that situation, the user must respond to the prompt,
> > or exit the minibuffer in some other way.  That's normal in my book.
> > What am I missing?
> 
> Emacs doesn't say anything.

It does: on the frame where you are in the minibuffer.

> The user is just typing into the void, and it's not easy get out of
> this state again, except C-x C-c. That's not normal.

My point is that this happens in many other, "simpler" situations.
AFAIK, it isn't limited to TTY frames, either.  So if that's the only
thing that happens here, i.e. some other frame is parked at the
minibuffer prompt, there's nothing new here that we didn't have before
child frames became supported on TTY displays.  Changing that would
need to have per-frame input queues in Emacs, AFAIU, and some way of
multiplexing between them.

But I'm not yet sure this is what we see in this case, which is why I
asked for a C backtrace.  Producing it should be easy: just reproduce
the problem, then attach a debugger and produce the backtrace.