unix中的signal用於通知程序中發生了非同步事件。使用者可以通過kill系統呼叫傳送乙個訊號，kernel自己內部也可以傳送訊號給乙個程序。
程序對訊號可以有三種處理方式：忽略，處理和預設（exit）。
為了傳送乙個訊號給乙個程序，核心設定相對應於訊號的bit位在程序的process table entry中，例如如果程序收到乙個kill signal，它將設定相應的bit位在process table signal field，但是程序不能得知它接收了多少次這個訊號。如果乙個程序睡眠在乙個可以被中斷的級別上，核心將會喚醒這個睡眠的程序，程序的傳送者至此完成任務。
核心僅當乙個程序從kernel mode返回user mode時才處理乙個訊號。如果乙個程序在user mode執行，且核心正在處理「乙個傳送訊號給這個程序」的中斷，核心將會在它返回user mode之前識別並且處理這個訊號。
程序可以通過signal(signmu,handler);系統呼叫設定對訊號的處理方式。在程序的u area中包含了乙個signal-hanlder field，對應每個signal num和相應的處理函式。
當處理乙個訊號時，核心確定訊號的型別，並在process table entry中設定該訊號的bit位。如果該訊號的處理方式被設定為default，核心將會在exit之前為此程序產生乙個" core"。但是核心不會為產生core如果沒有乙個程式錯誤發生，例如訊號sig_int和hang訊號。但是quit訊號仍然產生乙個core，即使它在程序執行環境外產生，這通常是使用者結束乙個無限迴圈等。
當程序接收到乙個訊號後，在返回user mode之前，核心會做一些事：
1，儲存的register context為返回user process。
2，清除在程序的u area中的signal handler field，設定它為default狀態（如果設定了「忽略」狀態，核心並不清除之前的「忽略」狀態，下次發生這個訊號時繼續忽略）。
3，核心建立乙個新的stack frame在使用者stack，呼叫訊號處理函式。
4，恢復1中儲存的register context，將pc指向signal-catcher的位址（訊號發生時）。
上述描述過程可能存在以下「異常」：
1，當程序返回到user mode之前，由於清除了u area中的signal handler field，只有再次呼叫signal系統呼叫時，才會再次撲捉到這個siganl，這是就可能存在乙個競爭條件。當再次呼叫signal之前，相同型號又發生了，這是程序就會exit（忽略情況除外）。（參看unix作業系統設計p207）
2，當乙個程序sleep在可被中斷的系統呼叫時，訊號會造成longjmp調出睡眠，返回user mode並呼叫訊號處理函式。當從訊號處理函式返回時，程序看起來像從系統呼叫返回並且帶有error表明此系統呼叫被中斷了。
3，當乙個程序sleep在不可被中斷的系統呼叫時，程序將被喚醒，但是不做longjmp。即只有核心喚醒睡眠程序並執行它時，才發現忽略了此訊號。
Go中的系統Signal處理
原文 我們在生產環境下執行的系統要求優雅退出，即程式接收退出通知後，會有機會先執行一段清理 將收尾工作做完後再真正退出。我們採用系統signal來 通知系統退出，即kill pragram pid。我們在程式中針對一些系統訊號設定了處理函式，當收到訊號後，會執行相關清理程式或通知各個子程序做自清理。...
WinCE中中斷的處理過程
中斷是硬體與軟體打交道的重要方法，因此，大多數驅動程式都涉及到對中斷的處理，本文就驅動程式的開發人員以及bsp的開發人員的角度，來談談windowsce中中斷的處理過程。如果乙個驅動程式要處理乙個中斷，那麼驅動程式需要首先建立乙個事件，可以使用createevent函式，然後呼叫interrupti...
Hadoop中mapReduce處理過程詳解
為了說明這個問題，我們使用wordcount的處理過程來進行演示，演示圖如下所示 分析上圖 1.輸入分片 input split 在進行map計算之前，mapreduce會根據輸入檔案計算輸入分片 input split 每個輸入分片 input split 針對乙個map任務，輸入分片 input...