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

[Lars Marowsky-Bree <lmb@suse.de>]

On 2004-10-17T19:54:04, Buddy Lucas <buddy.lucas@gmail.com> wrote:

> Sigh. Read the quote to which I responded again. Not a word about
> atomicity. Nowhere does it say that a descriptor which was ready for
> reading at select() time is still readable at recvmsg() time.

That is the _whole point_ of select() on non-O_NONBLOCK sockets.

> There is no doubt that it would be very nice if select() would say
> something useful, but that's not the issue here.

According to the specs, it says something useful. It doesn't on Linux,
agreed.

> > This isn't per se the same as saying that it's not a sensible violation,
> > but very clearly the specs disagree with the current Linux behaviour.
> So document it.

That's one way of doing it, yes.

> > If the packet has been dropped in between, which _could_ have happened
> > because UDP is allowed to be dropped basically anywhere, EIO may be
> > returned. But blocking or returning EAGAIN/EWOULDBLOCK is verboten. The
> > spec is very clearly on that.
> Obviously returning EAGAIN/EWOULDBLOCK while reading from a blocking
> fd is not what we want (in the situation at hand). I don't see how it
> relates to the discussion.

Others have suggested it in this thread as a possible error code, so
that's how it relates to this discussion. Surprise ;-)

> > I'm not so sure what's so hard to accept about that. It may be well that
> > Linux is following the de-facto industry standard (or even setting it)
> > here, and I'd agree that if you don't want blocking use O_NONBLOCK, but
> > in no way can Linux claim POSIX/SuV spec compliance for this behaviour.
> It doesn't.

*sigh* According to the man pages and the Linux Standard Base it does,
and it has been claimed repeatedly in this thread too.

Please get your facts straight.


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX AG - A Novell company