site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com User-agent: Thunderbird 2.0.0.12 (X11/20080213) EAGAIN comes from the nonblocking with no data ready. Ingemar, -- Steve Checkoway _______________________________________________ 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... Jordan K. Hubbard wrote: Your signal handler ("deadbeef") also should not be attempting to read from the pty since there are a lot of operations not considered safe from signal handlers (your results are guaranteed to be "undefined", if not outright incorrect). According to the man page for sigaction(2), read(2) is one of the base interfaces that is "either reentrant or not interruptible by signals and are async-signal safe [and therefore] applications may invoke them, without restriction, from signal-catching functions. The right thing to do is check for EAGAIN in your read() loop and go back and retry for the data in that case. Given that you're using O_NONBLOCK, it's even more important to make sure you handle all the async event cases. Do you mean EINTR? "If a signal is caught during the systems calls listed below [including read(2)], the call may be forced to terminate with the error EINTR, the call may return with a data transfer shorter than requested, or the call may be restarted." Rather than spam the list with my version of your code, you can get it here: <http://pahtak.org/~steve/child.c>. I would have just posted a diff like Jordan did, but I couldn't handle your inconsistent spacing. It seems to work correctly for me written that way. The signal handler in my version does nothing but set a flag and the while loop ends, not when the handler fires, but when read() returns 0, i.e., end of file. I didn't manage to get the signal to interrupt the read(), but that's probably because of the nonblocking IO. I'm not sure why you think you need unbuffered IO to avoid deadlocks or to deliver data quickly. As you probably noticed, printf() on the child side was buffering anyway. 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. This email sent to site_archiver@lists.apple.com