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

[Richard B. Johnson]

On Wed, 6 Oct 2004, David S. Miller wrote:

> On Wed, 6 Oct 2004 11:15:13 -0400 (EDT)
> "Richard B. Johnson" <root@xxxxxxxxxxxxxxxxxx> wrote:
>
> > On Wed, 6 Oct 2004, David S. Miller wrote:
> >
> > > On Wed, 6 Oct 2004 16:52:27 +0200 (CEST)
> > > Joris van Rantwijk <joris@xxxxxxxxxx> 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.

Any code that uses select() on the same file-descriptor
for several threads is broken. You can't explain away
a select() problem with a bad-coding example. Somebody
else responded that a bad checksum could do the same
thing --not. Select must return correct information.
The user-code doesn't know about, doesn't care, and
in many cases can't find out about, the inner workings
of an operating system.

When a function call like select() says there are data
available, there must be data available, period. If
not, it's broken and needs to be fixed. Requiring
one to set sockets to non-blocking is a poor work-
around for an otherwise fatal flaw.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.5-1.358-noreg on an i686 machine (5537.79 BogoMips).
            Note 96.31% of all statistics are fiction.

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