Non-blocking I/O with regular files

Every now and them, 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. And turning non-blocking mode on for a file descriptor will not prevent sleeping, other than by blocking. In other words, non-blocking operations can sleep. An arbitrary long time. Although the operating system will of course try to minimize that delay.

Blocking mode refers to one particular and well defined form of sleep: waiting until a file descriptor can be written to or read from. But 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, as this is the most common use case for non-blocking I/O. Writeability means the output buffers are not full as defined by the underlying socket protocol. This really mostly useful if the protocol implements some form of congestion control.
• For pipes, readability means there is some unread data in the pipe buffer, or one task is blocking in a write to the other end of the pipe. Reciprocally, writeability means there is room in the pipe buffer, 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 that they are duplex channels.
• For devices (other than terminals), polling is implementation-defined. You need to check with the device driver.
• 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 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 effect other than changing 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. That is of course true.

But 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's, 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 task. In other words, you need to create a separate thread, 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 could not be read ahead.