Linux下semop等待信號時出現Interrupted System Call錯誤(EINTR)解決方法

2020-01-26 16:06:49

字體：大中小

來源：轉載

供稿：網友

錯誤現象：(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，我們就可以從這個錯誤號來重新啟動我們的系統調用。

上一篇：解析c中stdout與stderr容易忽視的一些細節

下一篇：用c語言實現HUP信號重啟進程的方法