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

["Martijn Sipkema" <martijn@entmoot.nl>]

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