On Mar 25, 2008, at 6:39 PM, Steve Checkoway 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).
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.)
If you try his example checking for EINTR on
Leopard, at least, you'll still fail to catch that last "BYE" (try it).
Sure.
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...
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-dev/email@hidden
