Re: term bugs

[Roland McGrath]

> I don't know if this is a problem or not.  isatty should return if the file
> descriptor is associated with a terminal device, but is the master a
> terminal device in that sense?  Linux returns YES.

No, it's not.  BSD also returns no.

> This is exactly the same problem as when doing a cut & paste of more than
> 300 bytes in screen.  We really should fix that, as all other sane systems
> allow at least 512 bytes.  This is obviously related to the 300 byte hi
> watermark in term, but I am not sure if the 300 byte queue should work
> anyway.

That is the MAX_INPUT limit, which is also small (255) in Linux, though I
am not sure whether it is actually enforced.  That's the limit on the raw
input queue for a real terminal device.  I guess something different is
being done for ptys.  

> When the writer goes to sleep, it first wakes up the reader with
> bottom->start_output, should that do the job already?  I am a bit unsure how
> the code is supposed to work.

I too am just reading the code now to know what to tell you.  It wakes
anyone blocked in io_read or io_select, but that doesn't guarantee that
they will get scheduled, get the lock, and consume the queue before the
writer wants to write more.

> The limit in Linux seems to be 8061, after that it blocks.  

>From what I can see in kernel source, pty master writes are copied into a
temporary buffer of up to 2k and then inserted in the tty's buffer of 4k.
But there is a lot of hair in how all the various buffers are used and some
weird kludges in the pty stuff.