Messages in this thread | | | From | "Martijn Sipkema" <> | Subject | Re: UDP recvmsg blocks after select(), 2.6 bug? | Date | Wed, 6 Oct 2004 17:35:47 +0100 |
| |
From: "David S. Miller" <davem@davemloft.net> Sent: Wednesday, October 06, 2004 16:21 > 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.
Perhaps you should have elaborated then, because this is obviously not what was meant.
--ms
- 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/
| |