pty bugs & features

[Guy Harris]

>Why do pty's return EIO instead of 0 upon EOF?

Ask Berkeley.  The standard 4.3BSD pseudo-tty driver returns EIO if
nobody's holding the slave side open. 

>Is SunOS, Ultrix, or neither doing the "right" thing?

Beats me, what's "the 'right' thing?"

A program can probably deal with any sort of indication that the slave
side is closed, either a zero-length read or -1 and EIO.

If 4.3BSD compatibility is considered important, returning -1 and
setting "errno" to EIO is "the 'right' thing."

If one considers a zero-length read to be philosophically correct, or if
it simplifies programs that run on the master side of a pseudo-tty, or
something like that, returning -1 and setting "errno" to EIO isn't "the
'right' thing."

>If Ultrix is BSD-based and SunOS is SV-based,

SunOS is based on both BSD and S5, and also includes Sun stuff based on
neither of them.

SunOS's pseudo-tty driver is more based on the BSD one than on the S5
one, the fact that the slave side (but not the master side) in SunOS 4.x
is STREAMS-based nonwithstanding.

The S5R4 pseudo-tty subsystem (it's more than just a driver, it includes
a couple of STREAMS modules) returns an EOF (zero-length read)
when the slave side closes, rather than returning EIO.

>obviously this EIO behavior is common practice, yet I don't find any
>documentation on it, nor could a company engineer explain it.  What's
>the rationale?

Ask Berkeley, it was their idea.  We preserved it at Sun, and I assume
DEC did the same thing.  Other vendors probably did so as well.

>Why do stream's dump their buffers when the writer closes?

It has to do *something* with them when the queue is deleted, since
they're attached to that queue....

>I would think this could be a problem with other drivers besides ptys.

It could be.  Unfortunately, just about *any* close behavior is going to
screw *somebody*.

Waiting forever for output to drain can lock up a tty port forever if it
gets ^S'ed and there's output waiting.

Un-^S-ing when the port is closed screws terminals that depend on strict ^S/^Q
behavior (yes, this actually happened).  (System V Release "1"-to-3
behavior.)

Giving the port a finite amount of time to drain and then flushing
output means you can lose output if the port stays ^S'ed for too long. 
(SunOS 4.0[.x] and maybe S5R4 behavior; also S5R3 behavior if the vendor
has made any streams-based ttys.)

The ideal, at least for tty ports, is *probably* to wait until ^S is
received or "carrier" goes away (real carrier in the case of serial
ports; on pseudo-ttys, wait until ^S is recieved or the process on the
master side goes away), but I don't guarantee that this won't screw
anybody, either.  (This is, I think, what 4.3BSD does.)

>Or am I confused and is this just an error in the way the pty driver uses
>streams?  Is it possible to change this behavior using a flow control
>option without taking a severe hit in efficiency? (The manual alluded
>to this but didn't give enough to go on.)

I'm not sure where it alludes to this, nor why it does, nor what it
means by "a flow control option".

You can tweak processes on the slave side to wait for output to drain
using the TCSBRK "ioctl", but this means you have to change those
processes.

As I remember, we decided to change SunOS 4.1 to, in effect, wait
forever for output to drain, by having the "ldterm" streams module do
said "ioctl" internally for you as part of its "close" procedure, before
its queue gets destroyed and before any of the queues below it get
closed.

>What is it you are expected to do in 15 seconds?  It sure seems
>unusually large for internal system cleanup purposes.

It's not for internal system cleanup purposes; it's waiting for output
to drain.

>Yet it is worthless for user purposes if you can't make it infinite.  Why
>can't you change this number?

Ask AT&T, it was their idea.  I think I tried to sell them on having an
"ioctl" to change it at one point.