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

Martijn Sipkema
2004-10-07T13:13:56Z

From: "Paul Jakma" <paul@clubi.ie>
Sent: Thursday, October 07, 2004 13:53

> On Thu, 7 Oct 2004, Martijn Sipkema wrote:
>
> > That there is time between the select() and recvmsg() calls is not
> > the issue; the data is only checked in the call to recvmsg().
> > Actually the longer the time between select() and recvmsg(), the
> > larger the probability that valid data has been received.
>
> But it is the issue.
>
> Much can change between the select() and recvmsg - things outside of
> kernel control too, and it's long been known.

There is no change; the current implementation just checks the validity of
the data in the recvmsg() call and not during select().

> > But the standard clearly says otherwise.
>
> Standards can have bugs too.
>
> It's not healthy to take a corner-case situation from the standard on
> select() and apply it globally to all IO. (not in my mind anyway,
> whatever the standard says).

Read the standard. The behavious of select() on sockets is explicitely
described.

> > Perhaps select()'s perception of state should be made to take possible
> > corruption into account.
>
> You'll /still/ run into problems, on other platforms too. Set socket
> to O_NONBLOCK and deal with it ;)

What problems?

> > Why would the POSIX standard say recvmsg() should not block if
> > it did not intend it to be used in that way?
>
> POSIX_ME_HARDER? ;)

Would you care to provide any real answers or are you just telling
me to shut up because whatever Linux does is good, and not appear
unreasonable by adding a ;) ..?

> > Wrong. IMHO it is not exactly a good thing to not be compliant on
> > such basic functionality.
>
> Like I said, to my mind, any sane app should try avoiding assumption
> that kernel state remains same between select() and read/write - and
> O_NONBLOCK exists to deal nicely with the situation.
>
> You really shouldnt assume select state is guaranteed not to change
> by time you get round to doing IO. It's not safe, and not just on
> Linux - whatever POSIX says.

Any sane application would be written for the POSIX API as described
in the standard, and a sane kernel should IMHO implement that standard
whenever possible.

--ms