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

[Paul Jakma]

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.

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.

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

> 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(). ;)

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

Right.

> Chris

regards,
--
Paul Jakma	paul@xxxxxxxx	paul@xxxxxxxxx	Key ID: 64A2FF6A
Fortune:
A good reputation is more valuable than money.
		-- Publilius Syrus
-
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/