Re: Reading from a pty after slave exited
Re: Reading from a pty after slave exited
- Subject: Re: Reading from a pty after slave exited
- From: Terry Lambert <email@hidden>
- Date: Fri, 16 Apr 2010 15:36:44 -0700
On Apr 16, 2010, at 5:36 AM, Julian Scheid wrote:
The attached program works on Linux but fails on Darwin (OS X 10.6.3).
Linux will read "foo", on Darwin read returns 0.
It appears that the master-side file descriptor gets flushed when the
slave exits - any data written by the slave but not yet read by the
master appears to be lost at that point.
Moving the waitpid call behind the read solves the problem, but how
can I know for certain that the master has read all data? What if the
master process gets starved for whatever reason and doesn't manage to
drain the file descriptor by the time the slave exits?
BSD pty's differ from Linux/System V ptys in a number of important
ways, one of which is that it's very important to BSD to not lose data
when the pty is going away.
Because of this, operations for unsatisfied buffer space for writes
will block until either the other end reads them, or the other end
exits (this has avoided a common bug in svn where the file would be
truncated in some circumstances on non-BSD derived systems).
However, when you close the fd, since ptys are not implemented as
sockets, the operation will be permitted to proceed, realizing that if
you cared about the data, you wouldn't be closing the fd until it had
been acknowledged. This differs from systems where the underlying
implementation assumed a backing object equivalent to a socketpair().
If you want the other behaviour, you could always use socketpair()
instead.
Moving the wait changes the location of the child process reap, which
changes the location where the child descriptors are actually closed,
and so avoids this normal teardown. The reap is what tears down the
descriptors, not the exit itself.
There are also values such as VMIN and VTIME which can be used to
control the behaviour. There is a default timeout that's imposed as a
sap to POSIX conformance assuming non-BSD (lossy) pty behaviour, for
example, which if you set it to a large value, it will override the
default and cause it to block the write operation on the slave side.
These aren't the only differences in behaviour, but they're the ones
that are important for your specific case.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden