Date: Wed, 6 Oct 2004 08:21:45 -0700
From: "David S. Miller" <davem@davemloft.net>
To: root@chaos.analogic.com
Cc: joris@eljakim.nl, linux-kernel@vger.kernel.org
Subject: Re: UDP recvmsg blocks after select(), 2.6 bug?
Message-Id: <20041006082145.7b765385.davem@davemloft.net>
In-Reply-To: <Pine.LNX.4.61.0410061110260.6661@chaos.analogic.com>
References: <Pine.LNX.4.58.0410061616420.22221@eljakim.netsystem.nl>
	<20041006080104.76f862e6.davem@davemloft.net>
	<Pine.LNX.4.61.0410061110260.6661@chaos.analogic.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1202
Lines: 30

On Wed, 6 Oct 2004 11:15:13 -0400 (EDT)
"Richard B. Johnson" <root@chaos.analogic.com> wrote:

> On Wed, 6 Oct 2004, David S. Miller wrote:
> 
> > On Wed, 6 Oct 2004 16:52:27 +0200 (CEST)
> > Joris van Rantwijk <joris@eljakim.nl> wrote:
> >
> >> My understanding of POSIX is limited, but it seems to me that a read call
> >> must never block after select just said that it's ok to read from the
> >> descriptor. So any such behaviour would be a kernel bug.
> >
> > There is no such guarentee.
> 
> Huh?  Then why would anybody use select()?  It can't return a
> 'guess" or it's broken. When select() or poll() claims that
> there are data available, there damn well better be data available
> or software becomes a crap-game.

So if select returns true, and another one of your threads
reads all the data from the file descriptor, what would you
like the behavior to be for the current thread when it calls
read?

So like I said, there is no such guarentee.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/