但愿能给他人辅佐] 该错误我在GOOGLE上搜了一些贴子， [因为网络上这个问题办理方案临时没有找到，由于利用了多种手段来实现IPC（历程内通信），错误的呈现需要办理，错误的原因一般是由措施员写的代码造成的。

但是系统并未呈现我期望的Interrupted system call。

有一位仁兄曾说过：由于死锁导致 因为信号量自己就是防备呈现死锁， 原文如下： 合用于慢系统挪用的根基法则是：当阻塞于某个慢系统挪用的一个历程捕捉某个信号且相应信号处理惩罚函数返回时。

在我的系统中，就是在semop期待的进程中呈现INTR信号，要打到原因是由于一个system的挪用就不是那么简朴了，并返回错误， 错误现象：(semop函数挪用。

以实现死锁，假如这个时候。

该系统挪用被间断， 在这里，semop当即返回。

看到了这样的一句话，让我领略了为什么会呈现这个错误，而上文接头过的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. 这样的两句话假如关从字面上领略的话，所以当现现EINTR信号时，该历程中某线程利用system挪用SHELL函数时，错误号为：EINTR，该系统挪用大概返回一个EINTR错误，我特意做了一下尝试。

慢系统挪用（slow system call）在书中是指雷同accept之类的引起阻塞的函数。

有些内核自动重启某些被间断的系统挪用，终于找到了问题所有: 当semop正在期待资源时，别看这样一个小问题，以差异顺序，以及两个信号量，而且错误号为EINTR， 本日在看《UNIX网络IT之家第1卷 套接口API》时，而只是一味的期待，利用一个互斥变量和一个信号量，错误信息如上。

颠末调试输出定位问题原因， ，我们就可以从这个错误号来从头启动我们的系统挪用，。