site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com 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? -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... On Apr 16, 2010, at 5:36 AM, Julian Scheid wrote: 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. This email sent to site_archiver@lists.apple.com