Emacs has support for multiple X displays, each with their own
keyboard.  (The multi-tty branch uses the same mechanism to support
more than one tty device.)  To prevent interference from another
keyboard, Emacs sets single_kboard while reading from the minibuffer
or executing an interactive command.  When that variable is set, input
from other keyboards is stacked away unprocessed until it is reset to
zero.  Unfortunately, in some cases Emacs fails to clear
single_kboard, which causes problems.  For example, try the following
commands on a system that supports X forwarding via local ssh
connections:

        $ ssh -X localhost      # Create an alias for the current display
        Password: ******
          $ echo $DISPLAY
	  localhost:10
          $

        Then, from another terminal:

	$ emacs -q --no-site-file -f ignore	# Note the -f parameter!
        M-x make-frame-on-display <RET> localhost:10 <RET>

make-frame-on-display should succeed creating a new frame on the
forwarded X connection, but the new frame does not accept input; not
even C-g.  (Make sure you don't press C-g in the first frame, because
it unconditionally resets single_kboard and thus unfreezes the other
frame.)  The bug is triggered by specifying an interactive command to
be executed by the -f option.

But this is not the only time Emacs gets stuck in single_kboard mode.
Here is another (more frequent) case:

	$ emacs -q --no-site-file
        M-x make-frame-on-display <RET> localhost:10 <RET>
        slartibartfast C-x C-e    # void-variable error

        ==> The other frame is locked up, which might be
            intentional.  But exiting the debugger by
            pressing q does not help, which is certainly a bug.

(Pressing C-g on the single unlocked display always returns things to
normal, but finding that display is not always easy.)

Multi-tty users stumble upon these bugs quite frequently (e.g. `emacs
-f server-start' is a popular alias).  I attached a patch (adapted
from emacs--multi-tty--0--patch-189) that clears single_kboard each
time Emacs returns to top-level.  This seems to fix both bugs: