Oops, didn't mean to send this off list.
Jordan K. Hubbard wrote:
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
This email sent to email@hidden
