【转载】Non-blocking I/O with regular files

Every now and then, I hear some programmer complain that a given piece of code uses blocking I/O. The claim is typically that blocking I/O damages the responsiveness of applications, especially if it has a user interface. Hence, solely non-blocking I/O should be used, along with polling (poll() or select()) or an event handling framework (glib, Qt, etc).

I can sympathize with the goal of improving applications responsiveness.But that is not an excuse for mixing up blocking with sleeping. Blocking is just one of several ways to sleep. In other words, non-blocking operations can sleep. Indeed turning non-blocking mode on for a file descriptor will not prevent sleeping in all cases that it could occur, but only one (or two) of them (depending how you count).

Blocking mode refers to one particular and well defined form of sleep: waiting until a file descriptor can be written to or read from. What that really means depends on the type of the underlying file.

• For sockets, readability means there is some unread data in the input buffers. This is well-known and this is probably the most common use case for non-blocking I/O. Conversely, writeability implies the output buffers are not full as defined by the underlying protocol of the socket. This usually corresponds to congestion control, though the exact mechanisms and policies may vary.
• For pipes, readability means some unread data remains in the pipe buffer, or one task is blocking in a write to the other end of the pipe. Reciprocally, writeability means the pipe buffer has available room, or one task is blocking in a read operation on the pipe.
• FIFOs are really exactly like pipes, except that they have a name in the file system hierarchy.
• Terminals and pseudo-terminals also work much like pipes, with regard to I/O, except for the fact that they support duplex operations like sockets.
• For devices (other than terminals), polling is implementation-defined. You need to check the device driver documentation.
• For directories, polling is not defined. In any case, writing to directories is not allowed, and reading is only defined through synchronous APIs.
• Regular files are always readable and they are also always writeable. This is clearly stated in the relevant POSIX specifications. I cannot stress this enough. Putting a regular file in non-blocking has ABSOLUTELY no effects other than changing one bit in the file flags.

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

Nevertheless, non-blocking mode will not work. It simply will not work. Checking a file for readability or writeability always succeeds immediately. If the system needs time to perform the I/O operation, it will put the task in non-interruptible sleep from the read or write system call.

In other words, if you do know that a file descriptor refers to a regular file, do not waste your time, or worse, other people's time implementing non-blocking I/O. 
The only safe way to read data from or write data to a regular file while not blocking a task... is to not do it - in that particular task. Concretely, you need to create a separate thread (or process), whether you like it or not, even if you think threads suck (which usually really means you are an incompetent programmer who cannot use threads properly).

An alternative, of course, involves reading small chunks of data at once, and handling other events in-between. Then again, even reading a single byte can take a long time, if said byte was not read ahead by the operating system.