On Tue, 12 Oct 2004, Chad N. Tindel wrote: > > Does the POSIX standard _not_ give this implicit guarantee ? Whats the > > point in having a select call that says that the fd is readable, and when > > I go to read it the blocking read call blocks. Then either select returned > > a wrong positive or the read is buggy. > > The kernel should mark the socket readable (and hence select returns > > "readable") only after it has added the incoming data to the socket receive > > queue or it has changed the state of the socket (in case of TCP connections > > getting closed), in case of peer closing the connection. > > After that has been done, is the guarantee not there ? > > What you're saying is correct. However, if the UDP handler pulls the data > off of the receive queue and then finds that the datagram is corrupted, it > will go back into the read function to wait for another datagram. Personally > I think that it should return some other kind of error (not EAGAIN) to indicate > somehow that we discarded a datagram due to a bad checksum. Now I wonder whether the skb should be added to the UDP socket receive queue, only after checksum verification (as is done for TCP). I understand that, doing it that way we lose the advantage of folding copy-to-user and checksumming. If the standard does not explicitly write anything about the guarantee of read/write passing after successful return from select, then its fine; but somehow that does not sound very rational. If anyone can point to the specific section in the POSIX standard that dictates this, it will be of great help. Thanx, tomar > > Chad > -- -- You have moved the mouse. Windows must be restarted for the changes to take effect. - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
