site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com User-agent: Thunderbird 2.0.0.12 (Macintosh/20080213) Steve Checkoway wrote: /Ingemar _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... With a pty, it shouldn't buffer the pipe to a deadlock. That's the point. But maybe that is the problem, that pty's in Leopard buffer data when Tiger does not. Could be, I don't still have Tiger around to try. Then again, both Leopard and the version of Linux I was using before both buffer the printf() if I remove the fflush(). The difference is that Linux reports child quit, then it reads 16 bytes "hello!there!BYE!" whereas Leopard loses the data. This must be the loss you were describing. Maybe that is a bug, I'm not in a position to say. Jordan or Terry know far more than I. Exactly. Depending on buffering, the data may be early or late, but it should not just disappear. With too much buffering (which is what I get if I use pipes instead of ptys) the last data arrives in a big chunk at the end, but it does arrive at all. As a side note, this runs on (at least this particular flavor of) Linux as well with the small changes (included in the file) to include <pty.h> instead of <util.h> and to break out of the loop when read() returns -1 and errno is EIO. It is all built from common Unix calls so it should work. Didn't link in RHEL though, and that's the only Linux I have easily accessible. I don't have red hat, but it worked for me on both ubuntu (ppc) and fedora (x86). Did you remember to pass -lutil to gcc? You are right, I just missed -lutil. And it seems to work just fine, which means that RHEL seems to behave like Tiger. You're still using buffered IO in the signal handler. You simply cannot do that. Read the sigaction(2) man page. Well, I have had no problems with that, but that doesn't matter, it doesn't affect the real problem. I can do the whole thing without signals. So, Leopard is losing data when at least Tiger does not, and RHEL also seems to work. Under Leopard, you randomly lose data, sometimes it works but all too often it doesn't. I have found one solution that might do the trick. I spawn a pthread and let it sit and do blocking read()s, and whenever it gets something, it copies it over to a buffer that the main thread can poll. This solution needs some kind of semaphores when accessing common data, of course, but that can be done. I am testing this approach right now and it looks very promising No lost data at all so far. Another solution would be to make a pipe to a process that does these blocking read()s, and fflush() everything to the main program to get a smooth data flow. That is my conclusion so far. Thanks for the feedback! It is much appriciated! This email sent to site_archiver@lists.apple.com