Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!cme!libes
From: libes@cme.nist.gov (Don Libes)
Newsgroups: comp.unix.wizards
Subject: pty bugs & features
Message-ID: <5992@muffin.cme.nist.gov>
Date: 22 Aug 90 23:28:51 GMT
Organization: National Institute of Standards and Technology
Lines: 47

I've recently done some work with ptys and thought I'd share my
experiences with you - especially since the manuals weren't very
sharing for me.  I'm interested in comments.

The Sun 3/60 used is running SunOS4.1
The DecStation 3100 used is running V2.1.14

1) After slave side closes fd, master side read() returns -1.

master reads X seconds after slave close    Sun errno	Dec errno
             0				      5 (EIO)    35 (EWOULDBLOCK)
	    10				      5 (EIO)     5 (EIO)
	    20				      5 (EIO)	  5 (EIO)

I had expected read() to return 0 to indicate EOF.  The Sun engineer
said the manuals are in error not to document this behavior, but could
not explain why the driver was written this way.  Can anyone?

I didn't bother to call Dec, but I couldn't find that behavior
documented either, nor can I rationalize it.  (The fd was NOT marked
no-delay.)

2) After slave writes data and closes fd, the master side reads:

master reads X seconds after slave close	Sun	Dec
             0					data	data
            10					data	data
            20					-1,EIO	data

The Sun manual actually does document this, but doesn't phrase it
quite the way I'd say it.  Specifically, it is a byproduct of the
underlying streams implementation - "close() waits up to 15 seconds,
for each module and driver, for any output to drain before dismantling
the stream."

In other words, if you don't read your data quickly enough, you lose it!

The Dec behavior is what I would've expected.  The Sun engineer could
not explain where the number 15 came from, although he was kind enough
to point out that Sun Consulting could change it on my machine for a
small fee.  Otherwise it is not user-settable.

He said no one had ever reported these as bugs before.  He added that
they might their implementation [both (1) and (2)] in the future but
made no guarantees.  He did guarantee to change the manual, however.

Don Libes          libes@cme.nist.gov      ...!uunet!cme-durer!libes