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

[Neil Horman]

Hua Zhong wrote:
> > 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.
>
>
> Agreed.
>
>
> > 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.

Again, shouldn't this just mean that recvfrom should not be called 
without the MSG_ERRQUEUE flag set?  From the above description, I read 
that select returning with an indication that a descriptor is ready for 
reading could mean that it has an error message queued to it, rather 
than in-band data.  If you then call recvfrom/recv/recvmsg without 
indicating that you want to receive the error indications as well, then 
isn't that just another example of improper coding, since recvfrom would 
have returned immeidately, as select indicated, had the appropriate read 
flags been set?

Neil
> How hard is it to treat the next read to the fd as NON_BLOCKING, even if
> it's not set?
>
>
> > Andries
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


--
/***************************************************
 *Neil Horman
 *Software Engineer
 *Red Hat, Inc.
 *nhorman@xxxxxxxxxx
 *gpg keyid: 1024D / 0x92A74FA1
 *http://pgp.mit.edu
 ***************************************************/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/