在早期版本的unix系統中(比如說版本7)，訊號是不可靠的，意思是說訊號可能丟失：乙個訊號出現，但是程序可能永遠也不知道它，aslo,a process had little conrol over a signal: a process could catch the signal or ignore it, 有時候，我們希望告知核心阻塞乙個訊號:不要忽略它，當訊號出現的時候記住，然後在程序準備好以後通知程序。
在4.2bsd中做了修改，從而提供了一種稱為reliable signals的東西，在svr3上也做了另外一套修改，在system v上提供了可靠訊號，posix.1最後選擇了bsd模型來進行標準化。使用早期版本訊號處理的乙個問題是：在每一次訊號出現以後，訊號的處置方式就會被恢復到其預設處理方式(在前乙個例子中，我們僅僅執行每個訊號一次，所以避免了這個問題。)，描述這些早期系統的乙個典型例子關注了如何處理中斷訊號。其**描述看起來像如下所述:
signal 處理函式被宣告為返回乙個整形值的原因是:早期系統並不支援iso c的void資料型別.intsig_int
();/*my signal handling function*/
...
.signal
(sigint
,sig_int
);/*establish handler*/
...
sig_int()
上述**片段的問題是：在訊號已經生成一次之後，但是在呼叫signal handler裡面的signal函式之前，就會存在乙個時間窗，在這個時間窗內，如果再出現一次中斷訊號，那麼新出現的訊號就會造成一次預設處理，導致程序被終止，雖然在許多時候程序工作看起來是很正常的，但是這只是乙個假象。
這個早期版本的系統的另乙個問題是:程序不能夠關閉訊號，即是程序不想改訊號出現，所有程序可以實現的是忽略訊號。有些時候我們想要告知系統:防止如下訊號終止當前程序，但是如果他們出現的話請記住。闡述這一流程的典型事例如下所示：
在此，程序呼叫函式pause來將自身放到sleep狀態中去，直到捕獲到訊號，但訊號出現的時候，訊號處理函式會設定標誌sig_int_flag位乙個非零值。在訊號處理函式返回之後，程序被核心自動喚醒，程序檢查到標誌值非零，於是開啟執行其計畫的事情，但是存在乙個時間窗可能使得事情變得非常糟糕，如果訊號出現在檢查sig_int_flag之後但是有恰巧在pause之前，程序就可能永遠不能喚醒了(假設訊號從此不再產生)，那麼該訊號的出現就丟失了，這是一些**出現錯誤的例子，雖然在很多時間看起來是正確的，但是這只是乙個假象，除錯這種型別的錯誤是非常困難的。intsig_int
();/*my signal handling function*/
intsig_int_flag
;/*set nonzero when signal occurs*/
main()
...
}
sig_int()
來自為知筆記(wiz)
24 可靠訊號與不可靠訊號
以下整理 自 1 1 可靠訊號與不可靠訊號 1 訊號值小於 sigrtmin red hat 7.2 中，sigrtmin 32 sigrtmax 63 的訊號都是不可靠訊號。主要問題如下 程序每次處理訊號後，就將對訊號的響應設定為預設動作。在某些情況下，將導致對訊號的錯誤處理 因此，使用者如果不希...
學習筆記 可靠訊號 不可靠訊號
不可靠訊號pk可靠訊號 q linux訊號機制基本上是從unix系統中繼承過來的。早期unix系統中的訊號機制比較簡單和原始，後來在實踐中暴露出一些問題，它的主要問題是 q 程序每次處理訊號後，就將對訊號的響應設定為預設動作。在某些情況下，將導致對訊號的錯誤處理 因此，使用者如果不希望這樣的操作，那...
原始碼 訊號可靠訊號不可靠訊號相關
file main.c author luv letter created on 2017年3月14日,下午4 33 include include include include 3 訊號可靠訊號不可靠訊號相關 程式設計程式，要去實現如下功能 父程序建立子程序1和子程序2 子程序1向子程序2傳送可...