Re: pty behaviour

[Thomas Bushnell, BSG]

Marcus Brinkmann <address@hidden> writes:

> The pty_io_write implementation drops (flushes) all input if the queue
> is suspended (qavail returns 0).  This will be the case when the high
> watermark is reached.  Thus, if screen uses a single write to its pty
> end when the text is pasted, only up to the first 300 characters are
> written.

This is (or used to be) normal Unix tty behavior.  If you were on a
tty, and typed a bunch of characters which were not being read, then
when the buffer gets full, the tty driver eventually stops reading
input and beeps the bell.  So pty_io_write does just what all tty
input does in this respect.

The reason this was historically done was because of limited kernel
memory: you can't just have ever-expanding terminal buffers,
especially when they can be caused by noisy lines or the like.  If you
terminal was in line mode, this then imposed a limit on the longest
line you could type in Unix.

It indeed isn't that uncommon to have a key held down by something on
the keyboard, unattended.  (Ever had an emacs buffer get huge that
way?  I have.)  We don't want "kernel-level" services to be broken by
that kind of thing.

However, it does suck in this case!

We should certainly not change the tty behavior.  It's the Right
Thing.  Sticky keys do happen.

More details are needed to know how to fix the bug.  Can you figure
out the following:

  Is the pty in remote mode?
  Is IMAXBEL set?

Also, someone needs to do some research and determine (by reading the
source) what Linux and NetBSD do; they are the systems to track.

Thomas