Linux中signal機制闡述

最近同事的程式設計過程中用到了Linux的signal機制，從而引發了我對Linux中signal機制的思考。Signal機制在Linux中是一個非常常用的處理序間通訊機制，很多人在使用的時候不會考慮該機制是具體如何?的。signal機制可以被理解成進程的非強制中斷，因此，在即時性方面還是相對比較高的。Linux中signal機制的模型可以採用進行描述。

 

 

       每個進程都會採用一個進程式控制制塊對其進行描述，進程式控制制塊中設計了一個signal的位元影像資訊，其中的每位與具體的signal相對應，這與中斷機制是保持一致的。當系統中一個進程A通過signal系統調用向進程B發送signal時，設定進程B的對應signal位元影像，類似於觸發了signal對應中斷。發送signal只是“中斷”觸發的一個過程，具體執行會在兩個階段發生：

1、  system call返回。進程B由於調用了system call後，從核心返回使用者態時需要檢查他擁有的signal位元影像資訊表，此時是一個執行點。

2、  中斷返回。進程被系統中斷打斷之後，系統將CPU交給進程時，需要檢查即將執行進程所擁有的signal位元影像資訊表，此時也是一個執行點。

 

綜上所述，signal的執行點可以理解成從核心態返回使用者態時，在返回時，如果發現待執行進程存在被觸發的signal，那麼在離開核心態之後（也就是將CPU切換到使用者模式），執行使用者進程為該signal綁定的signal處理函數，從這一點上看，signal處理函數是在使用者進程上下文中執行的。當執行完signal處理函數之後，再返回到使用者進程被中斷或者system call（非強制中斷或者指令陷阱）打斷的地方。

 

       Signal機制實現的比較靈活，使用者進程由於中斷或者system call陷入核心之後，將斷點資訊都儲存到了堆棧中，在核心返回使用者態時，如果存在被觸發的signal，那麼直接將待執行的signal處理函數push到堆棧中，在CPU切換到使用者模式之後，直接pop堆棧就可以執行signal處理函數並且返回到使用者進程了。Signal處理函數應用了進程上下文，並且應用實際的中斷類比了進程的非強制中斷過程。