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

Neil Horman
2004-10-06T21:20:33Z

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@vger.kernel.org
> 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@redhat.com
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***************************************************/