site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com User-agent: Thunderbird 2.0.0.12 (X11/20080213) Oops, didn't mean to send this off list. On Mar 25, 2008, at 6:39 PM, Steve Checkoway wrote: Ah, I misunderstood. I thought you were saying he needed to check for EAGAIN because signals were interrupting the system call since that's what you were talking about in the sentences before and you only mentioned the nonblocking afterward. Of course he needed to check for EAGAIN because of the nonblocking. (I'm still not really sure why he wants that there in the first place though.) Sure. I didn't manage to get read() to be interrupted even when I removed the sleep call in the parent. I also didn't get it when I changed from nonblocking to blocking, but maybe it is just restarting the calls (I'm not seeing the default restart behavior listed in the man page). That said, I don't doubt that the signal can interrupt it. I just don't think that was his problem since he said it happened every time and I can't get it to happen even once (in my oh-so-scientific sample size of about 15 runs). -- Steve Checkoway -- 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: Jordan K. Hubbard wrote: 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." Nope, I do mean EAGAIN. In the context of non-blocking I/O, it's precisely what he needs to check for in this case, at least on MacOSX (other Unix variants may return EINTR instead - this is one of the grey areas of Unix behavior). If you try his example checking for EINTR on Leopard, at least, you'll still fail to catch that last "BYE" (try it). 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. Try shortening the sleep(2) intervals. You can get the race condition to happen fairly easily - I didn't express that change in my diffs since I didn't think it was relevant to the advice I was trying to give him... This email sent to site_archiver@lists.apple.com