This question already has an answer here:
As I have read from the book Computer Science: from A Programmer's Perspective, received signals are handled at the moment process shifts from kernel mode to user mode, usually returning from a system call or switching in a process context.
So why a system call can be interrupted by signals since signals are only handled when the system call returns?
Here is my guess. After the process context is switched-in, the kernel finds out that the current process is still blocked by a slow system call(such as
read), so it decided to discard the current system call and start a signal handling. It does not want to just simply switch the process context out because it's too expensive. And it does not want to block the process's signal handling by a slow system call forever for that makes the whole signal system lagging.
Is my assumption correct? Can you give me a detailed description about interrupting a system call? A web page link is welcomed.
Please note that my question is not similar to Interruption of system calls when a signal is caught. My question is about "why system call can be interrupted", and that one is about "why
read system call should be interrupted".