All, kuznet@ms2.inr.ac.ru wrote/schrieb/scribsit: > > According to the manpage select() on a nonblocking socket returns > > "readable" when a receive/read operation on the socket won't > > block. I've noticed that select occasionally returns a socket > > as "readable", but a following read() call will return EAGAIN. > > This is known "feature". If some signal is pending, tcp read > is interrupted even when some data is queued. It is wrong, of course. > However there is not contradiction with some standards: error is valid > as "readable" condition. > > This is not cleaned up because of some unintelligible problems with SIGURG, > which seems to want be handled before data read. It is something too obscure > to touch. 8) Would this happen with blocking sockets, too, and cause a read() to block infinitely? I've seen qmail-remote (smtp sender) block in read() on its socket at some rare occasions. However, this read() is directly preceded by a select() that must return the socket as readable for the read() to happen. This certainly makes a block on a (one byte) read() a "Cannot Happen". Please mind Mail-Followup-To when replying, since I'm not subscribed to linux-net. Thanks, Stefan - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org
