Often we will see such examples in the code of sleep:
if (signal_pending(current)) {
ret = - ERESTARTSYS ;
return right;
}
About- what exactly does ERESTARTSYS mean?
-ERESTARTSYS indicates that a certain system call before the signal function is re-executed after the signal function is processed.
In other words, if there is a system call before the signal function, before scheduling the user signal function, the kernel will check the return value of the system call to see if the system call was interrupted because of this signal. If the return value is -ERESTARTSYS, and the current The scheduled signal has the -ERESTARTSYS attribute, and the system will execute the system call after the user signal function returns
This process, you don't need to dig into it, you know the upper library functions. When you receive the return value of -ERESTARTSYS , for Linux, it will automatically call this call again.
As for
signal_pending (current) --- "Check whether the current process has signal processing, and return not 0 means there is a signal to be processed.
Scenario analysis:
1. When a system call is in a waiting state, such as waiting for the input buffer to be empty, a signal is generated at this time. This signal is only identified in the thread_info structure of the process, which is called "signaling" , And then wake up the system call of the process. After the system call wakes up, only use signal_pending () to check if there is a signal. Here, the signal is not processed. When there is a signal at this time, the system call returns ERESTARTSYS. When returning to user space, the corresponding signal processing function will be called according to the signal identification bit in thread_info. This is the so-called "receiving signal". For Linux, the upper library function will restart the system call according to the return value of the system call ERESTARTSYS, and for Solaris Will make the system call fail. In Linux, the restarted system call will check the buffer again, it is empty, indicating that the signal just now is not a signal that the buffer has data, continue to wait, repeat the process just now, not empty can process data directly, the system call ends normally
Note: The "signaling" Only the identity thread_info, check the signal system call to wake up, just signal_pending () when a judge to see if there is any signal identification, a true "to accept the signal" is returned from the system call thread_info in, or an exception handler returns, such as every When the clock interrupt processing function returns, check which signal in thread_info, and call the corresponding processing program to
supplement: For Solaris, the above situation, read is waiting, the buffer is full, wake up the read process, different from what we talk about here. signal"
1. When a system call is in a waiting state, such as waiting for the input buffer to be empty, a signal is generated at this time. This signal is only identified in the thread_info structure of the process, which is called "signaling" , And then wake up the system call of the process. After the system call wakes up, only use signal_pending () to check if there is a signal. Here, the signal is not processed. When there is a signal at this time, the system call returns ERESTARTSYS. When returning to user space, the corresponding signal processing function will be called according to the signal identification bit in thread_info. This is the so-called "receiving signal". For Linux, the upper library function will restart the system call according to the return value of the system call ERESTARTSYS, and for Solaris Will make the system call fail. In Linux, the restarted system call will check the buffer again, it is empty, indicating that the signal just now is not a signal that the buffer has data, continue to wait, repeat the process just now, not empty can process data directly, the system call ends normally
Note: The "signaling" Only the identity thread_info, check the signal system call to wake up, just signal_pending () when a judge to see if there is any signal identification, a true "to accept the signal" is returned from the system call thread_info in, or an exception handler returns, such as every When the clock interrupt processing function returns, check which signal in thread_info, and call the corresponding processing program to
supplement: For Solaris, the above situation, read is waiting, the buffer is full, wake up the read process, different from what we talk about here. signal"
--------------------------- --------------------------
static inline int signal_pending (struct task_struct * p)
{
return unlikely (test_tsk_thread_flag (p, TIF_SIGPENDING));
}
Transfer from: Resolution: signal_pending and return-ERESTARTSYS
