> > The docs for select() says: > > Under Linux, select() may report a socket file descriptor as > "ready for reading", while nevertheless a subsequent read > blocks. This could for example happen when data has arrived > but upon examination has wrong checksum and is discarded. > There may be other circumstances in which a file descriptor is > spuriously reported as ready. Thus it may be safer to use > O_NONBLOCK on sockets that should not block. > I never noticed this, and it is good that you brought it to our (my) attention. Maybe it does not need to be "fixed" in Linux. Maybe programming with sockets makes more sense to always be non-blocking... (I will likely adopt this as my new model of dealing with network sockets.) I found this interesting piece: http://www.kegel.com/dkftpbench/nonblocking.html What I really like about his discussion on this page (2nd example from top) is what he says in the code's comments about using a non-blocking open() for a socket: "Calling this on a socket causes all future read() and write() calls on that socket to do only as much as they can immediately, and return without waiting." I think we generally think of network programming like this, so why not make it always work that way. If the situation described in the man page is true in any case, we ought to be using non-blocking sockets and select(). (My apologies to all for this being a C++ example I am quoting, but you get the idea from the comment alone.) Which brings me to my next point: > I was thinking that poll() is also similarly afflicted on Linux, but > the docs for poll() don't mention anything similar. Does anyone > know if poll() used to have the problem, but no longer does > or if it does, but the docs fail to mention it? > > I was using poll() in this program: > https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/tiers/genz.cc > > but decided I could do without it recently. Part of my > decision was based on thinking that poll() suffered from > the same problem as select(). This problem with > select() has existed for years on LInux. I'm not sure why > they don't fix it. FreeBSD doesn't have this problem. > You are doing the right thing, even though it is for a different reasons. Do not use poll() for things that are not guaranteed to terminate. I never use poll(), and if you need one reason it is that you can easily "idle" a process with select() and proper timeouts than to constantly be taking up resources with a poll() call. I have a recommendation: look at other, open source, programs that are shipped with Linux distros and handle sockets that have asynchronous traffic, and see how they handle the calls that follow positive returns of sellect(). Let us know what you find.