In Non-Blocking IO - what is exactly does the IO?

Question

Even after a lot of reading I cannot seem to understand how non-blocking IO actually works at the OS level.

If a thread is the most granular unit to an OS scheduler, ie. any work that must be done must be done using a thread. Then which thread actually does the IO in non-blocking mode ?

Example:

Lets say a thread requests the contents of a socket in non-blocking mode, lets say the open system call in POSIX.

This basically means that the thread wants to be notified or will check a particular status for the completion of the IO. It does not wait for the IO to be completed. But my question is who does the IO ?

• Does the kernel spin up a thread to wait for the IO ? If so how is it different from the main thread spinning up a child thread and doing the same ?
• Most threads are mapped to kernel threads (green threads), then if non-blocking modes spin up threads then what's the great advantage ? All I get is my main thread not waiting.
• Are there other ways to complete IO without the use of threads ? Like Direct Memory Access (DMA) ? I have heard that it uses hardware interrupts (no idea how threads are not involved). So is all non-blocking IO, DMA ? Even reading from a disk ?

All these questions are basically the same: if NIO involves just spawning threads to do the waiting then how is it different from async IO, if not, then how is the IO even done ?

More info: There is no Thread

Answer 1

For simple, low-speed I/O devices (keyboard, mouse, serial ports, etc.) The CPU pretty much has to handle every byte of data. The secret sauce that makes that work is hardware interrupts.

When a hardware device needs attention from the CPU (e.g., because it has received a byte of data, and it needs the CPU to "read" the byte before the device is able to receive the next one) It signals an interrupt to the CPU.

The CPU handles the interrupt by;

• saving the the context of whatever thread was executing,
• possibly elevating the current privilege level, and then
• it effectively calls a function—the interrupt handler—that is responsible for servicing the hardware.

A typical interrupt handler for a low-speed I/O device might;

• read a byte from a register,
• maybe set a flag in another register,
• store the byte into a circular buffer, and then
• return.

The handler "returns" by executing a special "return-from-interrupt" opcode that restores the context of the thread that was interrupted, and restores the previous privilege level.

---

For high-speed I/O devices such as file storage devices or network interfaces, it's much the same except the hardware most likely will DMA entire blocks or packets of data to/from some physical memory buffer before it triggers the interrupt.