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

Martijn Sipkema
2004-10-09T18:21:21Z

From: "David Schwartz" <davids@webmaster.com>
> > > POSIX does not require the kernel to predict the future. The
> > > only guarantee
> > > against having a socket operation block is found in
> > > non-blocking sockets.
>
> > It is one thing to implement select()/recvmsg() in a non POSIX compliant
> > way; it is another thing to make false claims about that standard. POSIX
> > _does_ guarantee that a call to recvmsg() does not block after a call
> > to select().
>
> I do not believe this.
>
[...]
> Where, specifically, does the standard guarantee that a subsequent call to
> 'recvmsg' will not block?

When using select() on a socket for reading, select will block until
that socket is ready.

According to POSIX:

A descriptor shall be considered ready for reading when a call to an
input function with O_NONBLOCK clear would not block, whether or not
the function would transfer data successfully.

and

If a descriptor refers to a socket, the implied input function is the
recvmsg() function with parameters requesting normal and ancillary data,
such that the presence of either type shall cause the socket to be marked
as readable. The presence of out-of-band data shall be checked if the
socket option SO_OOBINLINE has been enabled, as out-of-band data is
enqueued with normal data. If the socket is currently listening, then it
shall be marked as readable if an incoming connection request has been
received, and a call to the accept() function shall complete without
blocking.

Thus recvmsg() shouldn't in any case block after a select() on a socket.

--ms