Five kinds of I/O models under Linux __linux

Five I/O models:

1 Blocking I/O (blocking I/O)
2 non-blocking I/O (nonblocking I/O)
3 I/O multiplexing (SELECT and poll) (I/O multiplexing)
4 Signal-driven I/O (signal driven I/O (Sigio))
5 Asynchronous I/O (asynchronous I/O (the POSIX aio_functions))

The first four are synchronized, and only the last one is asynchronous IO.

Blocking I/O models:
Introduction: The process will remain blocked until the data copy is complete
The application calls an IO function, causing the application to block and waiting for the data to be ready. If the data is not ready, wait .... The data is ready, copied from the kernel to the user space, and the IO function returns the success indicator.
Blocking I/O model diagram: When calling the Recv ()/recvfrom () function, the process of waiting for and replicating data in the kernel occurs.

When the recv () function is invoked, the system first checks for prepared data. If the data is not ready, then the system is in a waiting state. When the data is ready, copy the data from the system buffer to the user space, and the function returns. In a socket application, when the recv () function is invoked, the data is not necessarily in user space, then the recv () function is in the waiting state.
When you use the socket () function and the WSASocket () function to create a socket, the default socket is blocked. This means that when the Windows Sockets API is not immediately complete, the thread waits until the operation completes.
Not all Windows Sockets APIs will block with blocking sockets for parameter calls. For example, when the bind (), listen () function is called by a socket in blocking mode, the function returns immediately. The Windows Sockets API calls that may block sockets are grouped into the following four categories:
1. Input actions: recv (), Recvfrom (), WSARecv (), and WSARecvFrom () functions. Calls the function to receive data with a blocking socket as a parameter. If no data is readable within the socket buffer at this time, the calling thread sleeps until the data arrives.
2. Output operations: Send (), sendto (), WSASend (), and WSASendTo () functions. The function is called with a blocking socket to send data. If there is no free space in the socket buffer, the thread sleeps until there is room.
3. Accept connection: Accept () and wsaacept () functions. Call the function with a blocking socket, waiting to accept the other's connection request. If there is no connection request at this time, the thread will go to sleep.
4. Outgoing connection: Connect () and WSAConnect () functions. For TCP connections, the client invokes the function to initiate a connection to the server, with a blocking socket as a parameter. The function does not return until it receives a reply from the server. This means that the TCP connection always waits for at least one round-trip time to the server.
Using blocking-mode sockets, developing a network program is simpler and easier to implement. When you want to be able to send and receive data immediately, and handle theless socket number, it is more appropriate to use blocking mode to develop network programs.
Blocking mode sockets.Lack of performance, it is more difficult to communicate between a large number of established socket threads. When developing a network program using the producer-consumer model, assigning a read thread to each socket, a processing data thread, and an event for synchronization will undoubtedly increase the overhead of the system. The biggest drawback is that when you want to handle a lot of sockets at the same time, it will not be possible, its scalability is very poor

Non-blocking IO model:
Introduction: Non-blocking IO calls the IO function repeatedly through the process (multiple system calls and returns immediately); In the process of copying the data, the process is blocked;
We have set a socket interface to non-blocking is to tell the kernel, when the requested I/O operation cannot complete, do not sleep the process, but return an error. So our I/O operation function will constantly test whether the data is ready and, if not ready, continue testing until the data is ready. During this continuous testing process, the CPU time will be heavily occupied .
Setting the socket to non-blocking mode informs the system kernel that when you invoke the Windows Sockets API, you should not let the thread sleep, but you should let the function return immediately. When returned, the function returns an error code. As shown in the figure, a non-blocking-mode socket calls the RECV () function multiple times. The kernel data was not ready when the recv () function was called the first three times. Therefore, the function immediately returns the WSAEWOULDBLOCK error code. The fourth time the recv () function is called, the data is ready to be copied into the application's buffer, and the recv () function returns a successful indication that the application starts processing the data.

When you create a socket using the socket () function and the WSASocket () function, the default is blocked. After the socket is created, the socket is set to non-blocking mode by calling the Ioctlsocket () function.the functions under Linux are: Fcntl ().
When the socket is set to non-blocking mode, the calling function returns immediately when the Windows Sockets API function is invoked. In most cases, these function calls will call "failed" and return the Wsaewouldblock error code. Indicates that the requested operation does not have time to complete during the call period. Typically, the application needs to call the function repeatedly until a successful return code is obtained.
It is necessary to note that not all Windows Sockets APIs are invoked in Non-blocking mode and return Wsaewouldblock errors. For example, the bind () function is not returned when a socket with a non-blocking pattern is invoked as a parameter. Of course, the error code is not returned when the WSAStartup () function is invoked, because it is the first function called by the application and certainly does not return such an error code.
To set the socket to non-blocking mode, you can use the WSAAsyncSelect () and WSAEventSelect () functions in addition to the ioctlsocket () function. When the function is called, the socket is automatically set to non-blocking.
A wsaewouldblock error is often returned when a function is invoked using a non-blocking socket. So at all times, you should carefully review the return code and prepare yourself for failure. The application continuously calls this function until it returns a successful instruction. In the above list, the recv () function is continuously called in the while loop to read 1024 bytes of data. This practice is a waste of system resources.
To do so, someone uses the MSG_PEEK flag to invoke the recv () function to see if there is data readable in the buffer. Similarly, this method is not good. Because the overhead of this approach to the system is very large, and the application must call the recv () function at least two times to actually read the data. It is a good practice to use the socket's "I/O model" to determine whether a non-blocking socket is readable or writable.
Non-blocking-mode sockets are not easy to use compared to blocking-mode sockets. Using non-blocking-mode sockets, you need to write more code to handle the Wsaewouldblock errors that are received in each Windows Sockets API function call. Therefore, non-blocking sockets appear to be somewhat difficult to use.
However, non-blocking sockets in the control of the establishment of multiple connections, in the data received and received uneven, time is uncertain, obviously has the advantage. This socket is difficult to use, but as long as it eliminates these difficulties, it is still very powerful in function. In general, consider using the "I/O model" of sockets to help your application manage the communication of one or more sockets asynchronously.

IO Reuse Model:

Introduction: Mainly select and Epoll; for an IO port, two calls, two returns, have no advantage over blocking IO; The key is to achieve simultaneous monitoring of multiple IO ports;
The I/O multiplexing model uses the Select, poll, and Epoll functions, which also block processes, but unlike blocking I/O, these two functions can block multiple I/O operations at the same time. It is also possible to detect multiple read operations and multiple write I/O functions at the same time until the data is readable or writable, and the I/O operation function is actually invoked.

Signal-driven IO:
Synopsis: Two times call, two times return;
First we allow the socket to signal-drive I/O, and install a signal-processing function, and the process continues to run without blocking. When the data is ready, the process receives a sigio signal that calls the I/O operation function in the signal processing function to process the data.

Asynchronous IO Model:
Introduction: The process is not blocked when copying data.
When an asynchronous procedure call is issued, the caller cannot immediately obtain the result. When the part that actually handles this call is finished, it notifies the caller of the input and output operation through the state, the notification, and the callback

Synchronous IO causes the process to block until the IO operation completes.
Asynchronous IO does not cause the process to block.
Io multiplexing is first blocked by a select call.

Comparison of 5 I/O models:

Turn from: http://blog.csdn.net/klarclm/article/details/8828486