linux - should socket be set NON-BLOCKING before it is polled by select()? -

i have memory when want use select() on socket descriptor, socket should set nonblocking in advance.

but today, read source file there seems no lines set socket non-blocking memory correct or not?

thanks!

duskwuff has right idea when says

in general, not need set socket non-blocking use in select().

this true if kernel posix compliant regard select(). unfortunately, people use linux, not, linux select() man page says:

under linux, select() may report socket file descriptor "ready reading", while nevertheless subsequent read blocks. example happen when data has arrived upon examination has wrong checksum , discarded. there may other circumstances in file descriptor spuriously reported ready. may safer use o_nonblock on sockets should not block.

there discussion of on lkml on or sat, 18 jun 2011. 1 kernel hacker tried justify non posix compliance. honor posix when it's convenient , desecrate when it's not.

he argued "there may 2 readers , second block." such application flaw non sequiter. kernel not expected prevent application flaws. kernel has clear duty: in cases of first read() after select(), kernel must return @ least 1 byte, eof, or error; never block. write(), should test whether socket reported writable select(), before writing. guarantees can write @ least 1 byte, or error; never block. let select() you, don't write blindly hoping won't block. linux hacker's grumbling corner cases, etc., euphemisms "we're lazy work on hard problems."

suppose read serial port set for:

min n; -icanon, set n characters minimum completed read

time n; -icanon, set read timeout of n tenths of second

min 250 time 1

here want blocks of 250 characters, or 1 tenth second timeout. when tried on linux in non blocking mode, read returned every single character, hammering cpu. necessary leave in blocking mode documented behavior.

so there reasons use blocking mode select() , expect kernel posix compliant.

but if must use linux, jeremy's advice may cope of kernel flaws.