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

[Martijn Sipkema]

From: "Paul Jakma" <paul@xxxxxxxx>
Sent: Thursday, October 07, 2004 12:53


> On Thu, 7 Oct 2004, Chris Friesen wrote:
> 
> > Actually, in the single threaded case, the state did not change.  We just 
> > didn't actually check the state before returning from select().
> 
> Right, so our perception of state (which for all useful purposes /is/ 
> the state) changed - "we have data" -> "we had to throw out data due 
> to bad checksum" is a change in kernel state at least, if not in the 
> (now gone) data.
> 
> I'm not really a kernel person. From the application POV, in the 
> single-threaded case (cause the multi-threaded case is fairly 
> pathological anyway), there /will/ be time between the select and the 
> recvmsg, things /can/ change, and obviously they do.

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.

> Treating select as anything other than a useful hints mechanism is 
> going to get you into trouble - just see the Stevens' example others 
> gave for a long-standing example, in addition to this (sane imho) 
> Linuxism.

But the standard clearly says otherwise.

> > Actually, there wasn't.  The data was corrupt, therefore there was 
> > no data. Nothing changed with time, as the corrupt data was already 
> > present before we returned from select().
> 
> Perception of state is as good as state here.

Perhaps select()'s perception of state should be made to take possible
corruption into account.

> > POSIX says that if select() says a socket is readable, a read call 
> > will not block.  Obviously, we are not POSIX compliant.
> 
> Right, yes, that seems to be clear now.
> 
> Though, I'd still say that any app that calls read/write functions 
> without O_NONBLOCK set and that expects it will not block, is broken. 
> Basic common sense really, never mind the fine details of POSIX on 
> select(). ;)

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

> > There's nothing wrong with not being compliant, but it should be 
> > documented and we shouldn't claim to be compliant.
> 
> Right.

Wrong. IMHO it is not exactly a good thing to not be compliant on
such basic functionality.


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