The meanings of different types of files "readable and writable"

• For sockets, readability means there are some unread data in the receivebuffer. That's well-known and probably the most common use case for non-blocking I/O. Conversely, writeability implies the se nd buffer is not full from the standpoint of the underlying protocol of the socket (e.g. TCP/IP). Ultimately, protocol-specific congestion control determines the exact mechanisms and policies for the send buffer.
• For pipes, readability means some unread data remains in the pipe buffer, or one task was blocking in a write to the other End of the pipe. Reciprocally, writeability means the pipe buffer has available the class, or one task is blocking in a read operation on the PI Pe.
• FIFOs is really exactly like pipes, except that they has a name in the file system hierarchy.
• Terminals and Pseudo-terminals also work much like pipes, with regards to I/O, except for the fact, they support duple x operations like sockets.
• For devices (other than terminals), polling is implementation-defined. You need to check the device driver documentation.
• For directories, reading are only defined through blocking (synchronous) function calls, notably readdir() or readdir_r() . As such polling is isn't defined by the specifications and it would being of no use even if it were. Also writing to directories are not allowed on all.
• Regular files is always readable and they is also always writeable. This was clearly stated in the relevant POSIX specifications. I cannot stress this enough. Putting a regular file in non-blocking have absolutely no effectsother than changing one bit in the file flags.

Reading from a regular file might take a long time. For instance, if it's located on a busy disk, the I/O scheduler might take so much time that the user would notice that th E application is frozen.

Nevertheless, non-blocking mode would not fix it. It'll simply not work. Checking a file for readability or writeability always succeeds immediately. If the system needs time to perform the I/O operation, it'll put the task in non-interruptible sleep from the R EAD or write system call. In the other words, if you can assume the a file descriptor refers to a regular file, does not waste your time (or worse, other People ' s time) in implementing non-blocking I/O.

The only safe-to-read data from or write data to a regular file and not blocking a task ... consists of not performin G The operation-not in that particular task anyway. Concretely, need to create a separate thread (or process), or use asynchronous I/O (functions whose name starts with the c1/>). Whether you like it or not, and even if you think multiple threads suck, there is no other options.

From (http://www.remlab.net/op/nonblock.shtml)

The meanings of different types of files "readable and writable"