Path: utzoo!utgpu!watserv1!watmath!att!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!ncar!ico!dougm
From: dougm@ico.isc.com (Doug McCallum)
Newsgroups: comp.unix.internals
Subject: Re: problems with TCSETAF and rlogin
Keywords: termio, pseudo-tty, TCSETAF, rlogin
Message-ID: <1990Nov4.004655.4559@ico.isc.com>
Date: 4 Nov 90 00:46:55 GMT
References: <andy.657571549@xwkg>
Reply-To: dougm@ico.ISC.COM (Doug McCallum)
Organization: Interactive Systems Corp., Boulder CO
Lines: 30

In article <andy.657571549@xwkg> andy@xwkg.Icom.Com (Andrew H. Marrinson) writes:
...
>Further investigation revealed that this was due to a bug which was
>exercised whenever nn (or any other program) used TCSETAF under
>rlogin.  The manual page for TCSETAF states that it ``waits for output
>to drain, then flushes the input, then sets the parameters''.
>However, when using rlogin it seems that the output gets flushed as
>well.
...
>I urge everyone maintaining a system with the combination of BSD
>pseudo-ttys and System V/POSIX termio(s) to check their implementation
>for this bug.  

I did a little investigation and the problem is not in the pty driver
but in the generic tty code.  In the tty.c code for TCSETAF, a test
is done to see if it is a TCSETAF and then it calls ttyflush with both
the read and write flush bits set.  Our pty driver doesn't implement the
TCSETAF directly, it depends on the System V one.  A ttywait is done first,
but that only means that the data has been read by the server dealing with
the pty master side.  The next read will see the flush for both read and
write sides.  The additional steps taken in dealing with the network allow
for the flush to catch up with the data and then it is lost.

I would expect this problem to occur on all System V's regardless of the
origin of the pty driver unless the tty code is fixed.  Because of the
ttywait before the flush, this doesn't show up on a real tty.

Doug McCallum
Interactive Systems Corp
dougm@ico.isc.com