信号的其它特性
【摘自《Linux/Unix系統編程手冊》】
核心轉儲文件
特定信號會引發進程創建一個核心轉儲文件并終止運行。所謂核心轉儲是內含進程終止時內存映像的一個文件。將該內存映像加載到調試器中，即可查明信號到達時程序代碼和數據的狀態。
從 Linux 版本 2.6 開始，可以根據 Linux 特有的 /proc/sys/kernel/core-pattern 文件所包含的格式化字符串來控制對系統上生成的所有核心轉儲文件的命名。默認情況下，該文件所含字符串為 core。特權級用戶可以將該文件內容定義為下表中所列的人一個是說明符，待實際命名時再以表中右列所示相應值加以替換。此外，允許字符串中包含斜線（/），換言之，字符串不僅包含核心文件的名稱，還包括核心文件的所在（絕對或相對）目錄。替換所有格式說明符后，由此生成的路徑名字符串長度至多可達 128 個字符，超出部分將被截斷。
| ??? 說?? 明???符 ?? | ???????? 替???? 代 ??? 為??????? |
| %c | 對核心文件大小的資源軟限制（字節數；始于 Linux 2.6.24） |
| %e | 可執行文件名（不含路徑前綴） |
| %g | 遭轉儲進程的實際組 ID |
| %h | 主機系統的名稱 |
| %p | 遭轉儲進程的進程 ID |
| %s | 導致進程終止的信號編號 |
| %t | 轉儲時間，始于Epoch，以秒為單位 |
| %u | 遭轉儲進程的實際用戶 ID |
| %% | 單個 % 字符 |
?
信號的同步生成和異步生成
進程一般無法預測其接受信號的時間，這里的信號屬于異步生成，即引發信號產生（無論信號發送者是內核還是另一進程）的事件，其發生與進程的執行無關。
然而，有時信號的產生是由進程本身的執行造成的，例如使用 raise()、kill() 或者 killpg() 向自身發送信號，這種情況下，信號的產生就是同步的——會立即傳遞信號（除非該信號遭到阻塞），其傳遞不但可以預測，而且可以重現。
注意，同步是對信號產生方式的描述，并不針對信號本身。所有的信號既可以同步產生，也可以異步產生。
?
信號傳遞的時機與順序
- 何時傳遞一個信號？
同步產生的信號會立即傳遞。例如，硬件異常時會觸發一個即時信號，而當進程使用 raise() 向自身發送信號時，信號會在 raise() 調用返回前就已經發出。
當異步產生一個信號時，即時并未將其阻塞，在信號產生和實際傳遞之間仍可能會存在一個（瞬時）延遲。在此期間，信號處于等待狀態。這是因為內核將等待信號傳遞給進程的時機是，該進程正在執行，且發生由內核態 到用戶態的下一次切換時。實際上，這意味著在以下時刻才會傳遞信號：
1. 進程在前度超時后，再度獲得調度時（即，在一個時間片的開始處）
2. 系統調用完成時（信號的傳遞可能引起正在阻塞的系統調用過早完成）
- 解除對多個信號的阻塞時，信號的傳遞順序
如果進程使用 sigprocmask() 解除了對多個等待信號的阻塞，那么所有這些信號會立即傳遞給該進程。
就目前的 Linux 實現而言，Linux 內核按照信號編號的升序來傳遞信號。例如，如果對處于等待狀態的信號 SIGINT（信號編號2）和 SIGQUIT（信號編號3）同時解除阻塞，那么無論這兩個信號的產生次序如何，SIGINT 都將先于 SIGQUIT 而傳遞。然而，也不能對傳遞（標準）信號的特定順序產生任何依賴，因為 SUSv3 規定，多個信號的傳遞順序由系統實現決定。（該條款僅適用于標準信號）
當多個解除了阻塞的信號正在等待傳遞時，如果在信號處理器函數執行期間發生了內核態和用戶態之間的切換，那么將中斷此處理器函數的執行，轉而調用第二個信號處理器函數（如此遞進）
?
轉載于:https://www.cnblogs.com/jingyg/p/5189086.html
總結
- 上一篇： commons-logging log4
- 下一篇： PERL 实现微信登录