Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!mips!pacbell.com!pacbell!att!mcdchg!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.unix.internals
Subject: Re: pty bugs & features
Message-ID: <1990Sep04.035846.2211@chinet.chi.il.us>
Date: 4 Sep 90 03:58:46 GMT
References: <13650@smoke.BRL.MIL> <1990Aug29.153306.18173@chinet.chi.il.us> <3999@auspex.auspex.com>
Organization: Chinet - Chicago Public Access UNIX
Lines: 20

In article <3999@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:

>Prior to S5R3.2 or so, there was no way for a streams device to indicate
>that O_NDELAY should behave in the old tty driver fashion.  We (Sun) added a
>mechanism (basically S5R3.2-compatible) to the SunOS 4.0 streams code
>which was S5R3.1-based, because we knew this was a compatibility
>problem; apparently, the implementors of said tty emulations weren't as
>aware of this as we were.  One hopes the S5R3.2-based versions of those
>tty emulations are polite enough to request old-style behavior from the
>stream head....

Nope, the 3B2 SysVr3.2 still returns -1 on starlan tty emulation when
O_NDELAY is set and there is no data to read().  (Anyone wondering why
GNU Emacs or rn don't work right?).  And setting VMIN and VTIME to 0
doesn't prevent read() from blocking, either.  Oddly, the 386 version
of SysVr3.2 handles both correctly.


Les Mikesell
  les@chinet.chi.il.us