錯(cuò)誤現(xiàn)象：(semop函數(shù)調(diào)用，strerror(errno)輸出結(jié)果)

Interrupted system call

平臺：RedHat Linux

LINUX文檔關(guān)于EINTR的描述是這樣子的：

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

UNIX文檔［IEEE Std 1003.1-2008］關(guān)于EINTR的描述是這樣子的：

The semop() function was interrupted by a signal.

這樣的兩句話如果關(guān)從字面上理解的話，就是在semop等待的過程中出現(xiàn)INTR信號。

可是，錯(cuò)誤的出現(xiàn)需要解決，錯(cuò)誤的原因一般是由程序員寫的代碼造成的。

經(jīng)過調(diào)試輸出定位問題原因，終于找到了問題所有:

當(dāng)semop正在等待資源時(shí)，如果這個(gè)時(shí)候，該進(jìn)程中某線程使用system調(diào)用SHELL函數(shù)時(shí)，semop立即返回，并且錯(cuò)誤號為EINTR，錯(cuò)誤信息如上。別看這樣一個(gè)小問題，在我的系統(tǒng)中，由于使用了多種手段來實(shí)現(xiàn)IPC(進(jìn)程內(nèi)通信)，要打到原因是由于一個(gè)system的調(diào)用就不是那么簡單了。

[因?yàn)榫W(wǎng)絡(luò)上這個(gè)問題解決方案暫時(shí)沒有找到，希望能給他人幫助]

該錯(cuò)誤我在GOOGLE上搜了一些貼子，有一位仁兄曾說過：由于死鎖導(dǎo)致

因?yàn)樾盘柫勘旧砭褪欠乐钩霈F(xiàn)死鎖。我特意做了一下實(shí)驗(yàn)，使用一個(gè)互斥變量和一個(gè)信號量，以及兩個(gè)信號量，以不同順序，以實(shí)現(xiàn)死鎖，可是系統(tǒng)并未出現(xiàn)我期望的“Interrupted system call”，而只是一味的等待。

今天在看《UNIX網(wǎng)絡(luò)編程第1卷 套接口API》時(shí)，看到了這樣的一句話，讓我理解了為什么會(huì)出現(xiàn)這個(gè)錯(cuò)誤，原文如下：

“適用于慢系統(tǒng)調(diào)用的基本規(guī)則是：當(dāng)阻塞于某個(gè)慢系統(tǒng)調(diào)用的一個(gè)進(jìn)程捕獲某個(gè)信號且相應(yīng)信號處理函數(shù)返回時(shí)，該系統(tǒng)調(diào)用可能返回一個(gè)EINTR錯(cuò)誤。有些內(nèi)核自動(dòng)重啟某些被中斷的系統(tǒng)調(diào)用?！?/p>

在這里，慢系統(tǒng)調(diào)用(slow system call)在書中是指類似accept之類的引起阻塞的函數(shù)，而上文討論過的semop函數(shù)，我想應(yīng)該也是這一類的，所以當(dāng)現(xiàn)現(xiàn)EINTR信號時(shí)，該系統(tǒng)調(diào)用被中斷，并返回錯(cuò)誤，錯(cuò)誤號為：EINTR，我們就可以從這個(gè)錯(cuò)誤號來重新啟動(dòng)我們的系統(tǒng)調(diào)用。

總結(jié)

以上是生活随笔為你收集整理的linux 等待信号,51CTO博客-专业IT技术博客创作平台-技术成就梦想的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。