Re: UDP recvmsg blocks after select(), 2.6 bug?

Martijn Sipkema
2004-10-07T22:20:59Z

From: "Chris Friesen" <cfriesen@nortelnetworks.com>
> Martijn Sipkema wrote:
> > From: "Chris Friesen" <cfriesen@nortelnetworks.com>
>
> >>Since we wouldn't be posix compliant anyway in the nonblocking case, we may as
> >>well return EAGAIN--it's the most appropriate.
> >
> >
> > No, I don't think so, since POSIX says to return EAGAIN when:
> >
> > The socket's file descriptor is marked O_NONBLOCK and no data is waiting to
> > be received; or MSG_OOB is set and no out-of-band data is available and either
> > the socket's file descriptor is marked O_NONBLOCK or the socket does not
> > support blocking to await out-of-band data
>
> We are discussing the case where the socket is nonblocking and the udp checksum
> is corrupt, right? (Because in the blocking case select() would verify the
> checksum.)
>
> In this case, select() returns with the socket readable, we call recvmsg() and
> discover the message is corrupt. At this point we throw away the corrupt
> message, so we now have no data waiting to be received. We return EAGAIN, and
> userspace goes merrily on its way, handling anything else in its loop, then
> going back to select().
>
> Seems perfectly suitable.

Oh, I thought it was about the case where select() does not check the data and
a blocking socket is used and I would think EIO better in that case. But shouldn't
a nonblocking socket return EIO also, since the blocking socket would not in
fact block?

--ms