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".

marked as duplicate by user34720, Rui F Ribeiro linux Apr 3 at 13:26

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • this question is not like this question, as I explained in the question description. – John Apr 3 at 13:43
  • I voted to reopen, hopefully other reviews (5 are required total) will follow. – peterh Apr 3 at 14:17
  • "why system call can be interrupted" it is because it is. Take a look at the "Advanced Programming in the UNIX® Environment: 2nd Edition", 10.5. Interrupted System Calls - "...A characteristic of earlier UNIX systems is that if a process caught a signal while the process was blocked in a "slow" system call, the system call was interrupted. The system call returned an error and errno was set to EINTR. This was done under the assumption that since a signal occurred and the process caught it, there is a good chance that something has happened that should wake up the blocked system call...." – user34720 Apr 3 at 16:28
  • It's a thing from the past, and an implementation still maintained today – user34720 Apr 3 at 16:29
  • @nwildner the implementation is what I'm looking for. Can you give a brief description about the implementation? – John Apr 4 at 8:34