Eagain errors and EINTR errors in Linux network programming

In Linux, development often encounters many errors (setting errno), where Eagain is one of the more common errors (for example, in non-blocking operations).
Literally, it is a hint to try again. This error often occurs when the application is doing some non-blocking (non-blocking) operations (for files or sockets). For example, open the file/socket/fifo with the O_nonblock flag, if you do a sequential read operation and no data is readable. At this point the program does not block up and waits for the data to be ready to return, and the Read function returns an error eagain, prompting your application to now have no data to read please try again later.

For example, when a system call (such as fork) fails because there is not enough resources (such as virtual memory), the return eagain prompts it to be called again (perhaps next time it succeeds).

Linux-non-blocking socket programming handles Eagain errors
What does it mean when a non-blocking socket on Linux receives data that often appears resource temporarily Unavailable,errno code (eagain)?
This indicates that you have a blocking operation in non-blocking mode, which returns the error if the operation is not completed, which does not break the synchronization of the socket, regardless of the next loop and then recv. For non-blocking sockets, Eagain is not an error. On VxWorks and Windows, Eagain is named Ewouldblock.

EINTR Error:

Slow system calls (slow system call): This term applies to system calls that may be blocked for ever. A system call that is never blocked means that a call can never be returned, and most network support functions fall into this category. For example, if no client is connected to the server, then the server's accept call will not return the guarantee.

Eintr Error: When a process blocking a slow system call captures a signal and the corresponding signal processing function returns, the system call may return a EINTR error. For example: On the socket server side, set up a signal capture mechanism, a child process, when the parent process is blocked by a slow system call by the parent process to capture a valid signal, the kernel will cause accept to return a EINTR error (interrupted system call).

When encountering a eintr error, you can take some system calls that can be restarted to restart, and for some system calls, it is not enough to reboot. For example, functions such as accept, read, write, select, and open can be restarted. However, we cannot restart the Connect function in socket programming, and if the Connect function returns a EINTR error, we cannot call it again, or we will return an error immediately. The processing method that cannot be restarted for connect is that you must call select to wait for the connection to complete.

For socket Interface (refer to connect/send/recv/accept: And so on, do not repeat, do not include can not set non-blocking such as SELECT, in blocking mode may be due to a signal, return EINTR error, by the user to retry or terminate.

However, in non-blocking mode, is this error occurring?
In this, we revisit the system call, signal, socket related knowledge, concluded that: will not appear .

First of all
1. Signal processing is performed in the user state, that is, must wait for a system call to execute the signal function of the process, so there is a signal queue to save the non-executed signal
2. When the signal is interrupted by the user state, the kernel will record the interrupt address, and if the process has not exited, return to this address to continue execution.

The socket interface is a system call that, even if a signal is not interrupted, must wait for the socket interface to return before the process can process the signal.
That is, the EINTR error is the socket interface is actively thrown out, not the kernel throw. The socket interface can also choose not to return, its own internal retry and the like.

What happens when the socket interface handles the signal when it's blocked?

Example
The socket interface, such as the Recv interface, will do 2 things,
1. Check if buffer has data, then copy clear to return
2. No data, then go to sleep mode, when timeout, data arrival, error occurs wake process processing

Socket interface implementation is not too much, abstract said
1. If the resource is immediately available, the return
2. No, just wait ...

For
1. This time, no matter there is no signal, nor return to Eintr, just do their own on it.
2. Use sleep to wait, the process will wake up when the signal occurs, after the socket wake up check if there is no processing signal (signal_pending) will return EINTR error.

So
The socket interface is not interrupted by a signal, just a call to sleep, a signal sleep is awakened to the notification process, and then the socket interface chooses to exit actively, so that you can avoid blocking there, there is an opportunity to exit. Sleep is not called when it is not blocked.

Eagain errors and EINTR errors in Linux network programming