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

[Martijn Sipkema]

From: "Paul Jakma" <paul@xxxxxxxx>
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

-
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/