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

Paul Jakma
2004-10-07T11:53:54Z

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@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
A good reputation is more valuable than money.
-- Publilius Syrus