I/O Models

There are five I/O models under Unix:
1. blocking I/O
2. nonblocking I/O
3. I/O multiplexing (select and poll)
4. signal driven I/O (SIGIO)
5. asynchronous I/O (the POSIX aio_functions)
there are normally two distinct phases for an input operation:
6. Waiting for the data to be ready. involves waiting for data to arrive on the network. When the packet arrives, it is copied into a buffer within the kernel.
7. Copying the data from the kernel to the process. copying this data from the kernel’s buffer into our application buffer.
Blocking I/O Model
By default, all sockets are blocking.

The most common error is the system call being interrupted by a signal. We say that our process is blocked the entire time from when it calls recvfrom until it returns. When recvfrom returns successfully, our application processes the datagram.
Nonblocking I/O Model
we are telling the kernel “when an I/O operation that I request cannot be completed without putting the process to sleep, do not put the process to sleep, but return an error instead.”

The first three times that we call recvfrom, there is no data to return, so the kernel immediately returns an error of EWOULDBLOCK instead. The fourth time we call recvfrom, a datagram is ready, it is copied into our application buffer, and recvfrom returns successfully. We then process the data.
When an application sits in a loop calling recvfrom on a nonblocking descriptor like this, it
is called polling. The application is continually polling the kernel to see if some operation is
ready. This is often a waste of CPU time.
I/O Multiplexing Model
With I/O multiplexing, we call select or poll and block in one of these two system calls, instead of blocking in the actual I/O system call.

We block in a call to select, waiting for the datagram socket to be readable. When select
returns that the socket is readable, we then call recvfrom to copy the datagram into our
application buffer.
The advantage in using select is that we can wait for more than one descriptor to be ready.
Another closely related I/O model is to use multithreading with blocking I/O. That model
using select to block on multiple file descriptors, the program uses multiple threads (one per file descriptor), and each thread is then free to call blocking system calls like recvfrom.
Signal-Driven I/O Model
We can also use signals, telling the kernel to notify us with the SIGIO signal when the
descriptor is ready.

We first enable the socket for signal-driven I/O and install a signal handler using the sigaction system call. The return from this system call is immediate and our process continues; it is not blocked. When the datagram is ready to be read, the SIGIO signal is generated for our process. We can either read the datagram from the signal handler by calling recvfrom and then notify the main loop that the data is ready to be processed or we can notify the main loop
and let it read the datagram.
the advantage to this model is that we are not blocked while waiting for the datagram to arrive. The main loop can continue executing and just wait to be notified by the signal handler that either the data is ready to process or the datagram is ready to be read.
Asynchronous I/O Model
In general, these functions work by telling the kernel to start the operation and to notify us when the entire operation (including the copy of the data from the kernel to our buffer) is complete. The main difference between this model and the signal-driven I/O model is that with signal-driven I/O, the kernel tells us when an I/O operation can be initiated, but with asynchronous I/O, the kernel tells us when an I/O operation is complete.

We call aio_read and pass the kernel the descriptor, buffer pointer, buffer size (the same three arguments for read), file offset (similar to lseek), and how to notify us when the entire operation is complete. This system call returns immediately and our process is not blocked while waiting for the I/O to complete. We assume in this example that we ask the kernel to
generate some signal when the operation is complete. This signal is not generated until the
data has been copied into our application buffer, which is different from the signal-driven
I/O model.
Comparison of the I/O Models
the main difference between the first four models is the first phase, as the second phase in the first four models is the same: the process is blocked in a call to recvfrom while the data is
copied from the kernel to the caller’s buffer. Asynchronous I/O, however, handles both phases and is different from the first four.

Synchronous I/O versus Asynchronous I/O
1. A synchronous I/O operation causes the requesting process to be blocked until that I/O operation completes.
2. An asynchronous I/O operation does not cause the requesting process to be blocked.
the first four I/O models blocking, nonblocking, I/O multiplexing, and signal-driven I/O are all synchronous because the actual I/O operation (recvfrom) blocks the process. Only the asynchronous I/O model matches the asynchronous I/O definition.