Linux下semop等待信号时出现Interrupted System Call错误(EINTR)

错误现象：(semop函数调用，strerror(errno)输出结果)

Interrupted system call

平台：RedHat Linux

LINUX文档关于EINTR的描述是这样子的：

While blocked in this system call, the process caught a signal.

UNIX文档［IEEE Std 1003.1-2008］关于EINTR的描述是这样子的：

The semop() function was interrupted by a signal.

这样的两句话如果关从字面上理解的话，就是在semop等待的过程中出现INTR信号。

可是，错误的出现需要解决，错误的原因一般是由程序员写的代码造成的。

经过调试输出定位问题原因，终于找到了问题所有:

当semop正在等待资源时，如果这个时候，该进程中某线程使用system调用SHELL函数时，semop立即返回，并且错误号为EINTR，错误信息如上。别看这样一个小问题，在我的系统中，由于使用了多种手段来实现IPC（进程内通信），要打到原因是由于一个system的调用就不是那么简单了。

[因为网络上这个问题解决方案暂时没有找到，希望能给他人帮助]

该错误我在GOOGLE上搜了一些贴子，有一位仁兄曾说过：由于死锁导致

因为信号量本身就是防止出现死锁。我特意做了一下实验，使用一个互斥变量和一个信号量，以及两个信号量，以不同顺序，以实现死锁，可是系统并未出现我期望的“Interrupted system call”，而只是一味的等待。

今天在看《UNIX网络编程第1卷 套接口API》时，看到了这样的一句话，让我理解了为什么会出现这个错误，原文如下：

“适用于慢系统调用的基本规则是：当阻塞于某个慢系统调用的一个进程捕获某个信号且相应信号处理函数返回时，该系统调用可能返回一个EINTR错误。有些内核自动重启某些被中断的系统调用。”

在这里，慢系统调用（slow system call）在书中是指类似accept之类的引起阻塞的函数，而上文讨论过的semop函数，我想应该也是这一类的，所以当现现EINTR信号时，该系统调用被中断，并返回错误，错误号为：EINTR，我们就可以从这个错误号来重新启动我们的系统调用。