Advice sought: pty/tty gets into "gridlock" if it does too much input/output while stopped

[Joe Peterson <joe@skyrush.com>]

I've been investigating an issue I ran into recently, and I am not yet sure how
to fix it, so I am soliciting suggestions.

Basically, it is quite easy to "gridlock" (I avoided the term "deadlock", since
this is not a locking issue) a shell/xterm session by stopping the tty (e.g.
hitting ^S) and then causing lots of input and output.  Here is an easy way to
do it:

1) open an xterm
2) type "grep foo"
3) hit ^S
4) paste a large number of lines (more than the 4k size)
   containing the word "foo" (this causes output for every input)

There is now no way to break out of this condition in a normal way.  Signals
(e.g. ^C, ^Z) and ^Q cannot break out of this state, since the input character
cannot make it into the line discipline (I never see it in the buffer in
pty_write() after the condition takes hold).  The only thing that can be done is
to close the xterm window.

The problem is that pty_write() (when trying to process typed characters) finds
that "to->receive_room" is zero, so no data is passed to n_tty_receive_buf(),
and nothing can move.  Since both the reads and writes (both of which pass
through the pty_write() function) are waiting to have some space with which to
work, and the tty is stopped, things are stuck.  Since signal and ^Q chars do
not need buffer space, perhaps these could (perhaps) get a higher priority and
be sent through, but since I do not see them in the pty_write() buffer when
issued *during* the condition, it is not clear where this should be done, or if
it is the right solution.  I've verified this as far back as 2.6.24.

							-Joe