UNIX Network Programming Reading Notes: I/O model (blocking, non-blocking, I/O multiplexing, signal-driven, asynchronous)

I/O model

Five I/O models available in UNIX:

(1) blocking I/O

(2) non-blocking I/O

(3) I/O multiplexing (select and poll)

(4) signal-driven I/O (SIGIO)

(5) asynchronous I/O

For input operations on a set of interfaces, the first step usually involves waiting for data to arrive from the network. When the waiting group arrives, it is copied to a buffer in the kernel. The second step is to copy data from the kernel buffer to the application process buffer.

1. Block I/O model

The most popular I/O model is the block I/O model. By default, all interfaces are blocked.

The following uses the datagram interface as an example:

When a process calls recvfrom, its system call will not be returned until the datagram arrives and is copied to the buffer zone of the application process or when an error occurs. The most common error is that a system call is interrupted by a signal.We say that the process is blocked for the whole period from the time when recvfrom is called to the time it returns.. After a successful response from recvfrom is returned, the application process starts to process the data.

2. Non-blocking I/O model

The process sets a set of interfaces as non-blocking in notifying the kernel:When the requested I/O operation must put the process into sleep to complete, do not put the process into sleep, but return an error. Demonstrate non-blocking I/O models.

No data can be returned when recvfrom is called three times before, so the kernel returns an EWOULDBLOCK error immediately. When recvfrom is called for the fourth time, the existing datagram is ready. It is copied to the application process buffer, and recvfrom is returned successfully. We then process the data.

When an application process calls recvfrom cyclically for a non-blocking descriptive word like this, we call itPolling). The application process continuously polls the kernel to check whether an operation is ready. This often takes a lot of CPU time, but this model is occasionally encountered, usually only in systems that provide a specific function.

3. I/O Reuse Model

With I/O multiplexing (I/O multiplexing), we canCalling select or poll blocks one of the two system calls, rather than blocking the real I/O system calls.. Demonstrate the I/O Reuse Model.

We blocked the select call and waited for the datagram set interface to become readable. When select returns the set interface readable condition, we call recvfrom to copy the read datagram to the application process buffer.

Comparing the I/O Reuse Model and the blocking I/O model, I/O Reuse does not show any advantages. In fact, because select requires two instead of a single system call, i/O reuse also has some disadvantages.The advantage of using select is that we can wait for multiple descriptive words to be ready.

Another I/O model closely related to I/O multiplexing is the use of blocking I/O in multithreading. This model is very similar to the I/O Reuse Model. Instead of blocking multiple file descriptors using select, multiple threads are used (one thread for each file description ), in this way, every thread can freely call a blocking I/O system call such as recvfrom.

4. Signal-driven I/O model

We can also use signals,Let the kernel send a SIGIO signal to notify us when the description word is ready. We call this model signal-driven I/O (signal-driven I/O), As shown in:

We first enable the signal-driven I/O function of the set of interfaces, and install a signal processing function through the sigaction system call. The system call immediately returns, and our process continues to work, that is, it is not blocked. When the datagram is ready for reading, the kernel generates a SIGIO signal for the process. Then we can call recvfrom in the signal processing function to read the datagram, notify the main loop that the data is ready for processing, or immediately notify the main loop to read the datagram.

Regardless of how the SIGIO signal is processed, the advantage of this model is that the process is not blocked while waiting for the datagram to arrive. The main loop can continue to be executed, as long as you wait for a notification from time to time from the signal processing function: either the data is ready to be processed or the data is ready to be read.

5. asynchronous I/O model

Asynchronous I/O is defined by the POSIX specification.Generally, these functions work by notifying the kernel to start an operation and letting the kernel perform the entire operation (including copying data from the kernel to our own buffer) notify us after completion.The main difference between this model and the signal-driven model is that the signal-driven I/O is used by the kernel to notify us when to start an I/O operation, the asynchronous I/O model informs us when I/O operations are completed by the kernel.

We call the aio_read function (POSIX asynchronous I/O function starts with aio _ or lio _) and pass the description, buffer pointer, and buffer size to the kernel (three parameters identical to read), file offset (similar to lseek), and tell the kernel how to notify us when the entire operation is completed. This system call returns immediately. Our processes are not blocked while waiting for I/O to complete.

6. Comparison of various models

7. synchronous I/O and asynchronous I/O

POSIX defines the two terms as follows:

• Synchronous I/O operations (synchronous I/O operation) cause the request process to be blocked until the I/O operation is completed.
• Asynchronous I/O operation does not cause request process blocking.

According to the above definition, our first four models-blocking I/O models, non-blocking I/O models, I/O multiplexing models, and signal-driven I/O models are all synchronous I/O models, because the real I/O operation (recvfrom) will block the process. Only the asynchronous I/O model matches the asynchronous I/O defined by POSIX.