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

Previous Next

Full log

View this message in rfc822 format

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Len Trigg <lenbok <at> gmail.com>
Cc: 75056 <at> debbugs.gnu.org
Subject: bug#75056: 31.0.50; tty-child-frames with server / multiple clients possible hangs
Date: Fri, 27 Dec 2024 07:04:54 +0100

Len Trigg <lenbok <at> gmail.com> writes:

> tty-child-frames does not seem to play well with multiple clients. When we run server-start and allow emacs to have
> multiple clients (e.g. an initial "emacs -nw" and an
> "emacsclient -nw"), using a function that utilizes tty-child-frame (such as M-x when vertico-posframe is loaded) in one
> frame leads the other client to be locked up.
>
> Steps to reproduce:
>
> mkdir ~/emacs-test
> Copy the attached init.el into ~/emacs-test/
> emacs -nw --init-directory=~/emacs-test  (the first time will result in packages being installed by elpaca)
> (in another terminal) emacsclient -nw
> Do something to invoke the child frame pop up (e.g. C-x b and select a buffer)
> Switch back to the original emacs
> Do something to invoke the child frame pop up (e.g. C-x b and select a buffer)
> Swap to the other terminal, and note that at some point one client will stop responding
> to user input. (It may take a couple of tries, perhaps with other regular commands interspersed).
> When one client is locked, swap back to the other terminal and exit the client - the original
> client will now accept user input.
>
> When a client is locked it *does* accept some input (e.g. C-x C-c will exit the client)
>
> It's possible this is vertico-posframe related, as I can't trigger similar behaviour using transient-posframe.
>

Hi Len, and thanks for the nice reproducer!

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.

@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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.