Messages in this thread | | | Date | Wed, 6 Oct 2004 12:07:43 -0400 (EDT) | From | "Richard B. Johnson" <> | Subject | Re: UDP recvmsg blocks after select(), 2.6 bug? |
| |
On Wed, 6 Oct 2004, David S. Miller wrote:
> On Wed, 06 Oct 2004 09:31:46 -0600 > Chris Friesen <cfriesen@nortelnetworks.com> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |