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

[Andries Brouwer <aebr@win.tue.nl>]

On Wed, Oct 06, 2004 at 08:04:29PM +0200, Joris van Rantwijk wrote:

> > On Mer, 2004-10-06 at 15:52, Joris van Rantwijk wrote:
> > > My understanding of POSIX is limited, but it seems to me that a read call
> > > must never block after select just said that it's ok to read from the
> > > descriptor. So any such behaviour would be a kernel bug.

Alan answers - and I don't like his answer a bit:

> > Select indicates there may be data. That is all - it might also be an
> > error, it might turn out to be wrong.
> >
> > You should always combine select with nonblocking I/O

Joris replies again:

> Sorry about my wrongly blaming the kernel. I do think this issue shows hat
> the select(2) manual needs fixing.

It may need fixing in the sense that it must point out that the Linux kernel
might not conform to POSIX in its handling of select on sockets.

We now not only have "man 2 select", but also "man 3p select".
This is the POSIX text:

       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. (The function might return data, an  end-of-
       file  indication,  or  an  error other than one indicating
       that it is  blocked,  and  in  each  of  these  cases  the
       descriptor shall be considered ready for reading.)

As far as I can interpret these sentences, Linux does not conform.

Andries


Neil Horman wrote:

>> I think you could also pass the MSG_ERRQUEUE flag to the recvfrom call 
>> and receive the errored frame, eliminating the case where errored frames 
>> might cause you to block on a read after a good return from a select call.

davem wrote:

>> There is no such guarentee.

>> Incorrect UDP checksums could cause the read data to
>> be discarded.  We do the copy into userspace and checksum
>> computation in parallel.  This is totally legal and we've
>> been doing it since 2.4.x first got released.


ahu wrote:

>> This can happen, and is fully to be expected. For a host of reasons the
>> packet might not in fact appear. Whenever using select for non-blocking IO
>> always set your sockets to non-blocking as well.

>> One of the legitimate reasons is the reception of packets which, on copying,
>> turn out to have a bad checksum.

>> Stevens has a section on this, recommended reading.

Reference?