select and O_NONBLOCK

"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. "

but if i use O_NONBLOCK then also select does not block if there is not data??

I'd say try it out. I think select will block even if the only supplied fd is non-blocking, until there has been a change in status.

the manpage says: "[...]Three independent sets of descriptors are watched. Those listed in readfds will be watched to see if characters become available for reading (more precisely, to see if a read will not block [...]"

Man pages say a lot. My select manpage contains this gem:
"No doubt, since POSIX.1-2001, it should give the prototype by default."

So what, now the manpage is guessing how things work? Dude, just check the damn source before you write the docs.

Well, don't trust the manpage. If the behavior is as you guess, that's easy to test for. Create a socket to yourself that is O_NONBLOCK and select() on it. If it returns immediately, you have a problem. If it blocks forever, you don't.

Quote:

---

So what, now the manpage is guessing how things work? Dude, just check the damn source before you write the docs.

---

People writting those pages are not paid for it (and even so...), you can't expect it to be perfect.
They are mostly correct, and I think the "don't trust the manpages" is a bit too extreme ;)

whatever, I did the test out of curiosity (using the standard input as stream and using it with and without the O_NONBLOCK flag) and select() waits patiently in both cases. The world is safe.

edit: well, you can't trust me either so the OP also has to do the test...