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

[Richard B. Johnson]

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

> On Wed, 06 Oct 2004 09:31:46 -0600
> Chris Friesen <cfriesen@xxxxxxxxxxxxxxxxxx> wrote:
>
> > David S. Miller wrote:
> >
> > > 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?
> >
> > What about the single-threaded case?
>
> Incorrect UDP checksums could cause the read data to
> be discarded.  We do the copy into userspace and checksum
> computation in parallel.  This is totally legal and we've
> been doing it since 2.4.x first got released.
>
> Use non-blocking sockets with select()/poll() and be happy.

Gawd. This is damn awful. How could this possibly be justified?
You can't have a system call that lies. We already have an OS
that does that. Certainly, no other Unix OS in the past has
thrown away integrity with such aplomb. Next, in the interest
of "performance", you'll probably only occasionally provide
file-data, as well.

You can't do this. When there is some well-defined procedure
such as select() or poll(), that is designed to provide a
reliable way of knowing that a read will succeed, you or
anybody else don't have the authority to declare that it's
not important to actually have it work.

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/