無阻塞信號傳輸需要多長時間？

Question

1. 當一個進程向另一個進程發送信號時，在什麼情況下接收進程會等待它重新計劃運行？
2. 在什麼情況下立即調用已安裝的信號處理程序？
3. 與僅直接調用相應的信號處理程序相比，提升信號時該過程會產生多少開銷？

Answer 1

關於分娩的信號，TLPI指出信號是「正常」時，任務下次計劃，從內核模式切換到用戶模式時，或交付「立即」當任務已經運行（大概是「立即「必須先發生中斷才能發生，否則它會怎麼做）。那麼，無論這意味着什麼，它不是嚴格的約束，但它與發生的事情非常接近。

您必須區分實時信號和「正常」信號以及同步生成的「正常」信號，大部分時間由於硬件事件（例如分段故障）而不是（它們） '異步生成）。

實時信號排隊排隊，正常信號不是。這意味着正常信號的實現很可能僅僅是像一個任務字一樣用作位掩碼。生成一個「正常」信號意味着設置一個位，並且當操作系統接下來決定是否必須傳遞一個信號時，它將該字對零進行測試，並在必要時確定設置了哪個位，然後調用信號處理程序（如果有的話）。
爲什麼人們需要知道這一點唯一的實際原因是因爲它有可能「丟失」信號。如果兩個或更多的信號在第一個信號傳輸之前生成，它仍然只有一個信號。

實時信號的實現顯然要複雜得多（需要排隊等待實現的長度）。

由於硬件事件（例如段錯誤）而發生的信號是以同樣的方式生成的，就好像其本身稱爲kill（章節22.4 TLPI）的過程一樣，即它們是「立即」傳送的，原因有兩個。首先，做其他事情沒有意義，其次，當陷阱處理程序返回時，已經有內核/用戶切換髮生。所以交付總是「立即」。

Answer 2

基本上，信號是異步的。當信號被接收時，它們依靠信號處理程序來執行代碼，因爲你永遠不知道什麼時候會由於諸如進程調度程序等因素。發送信號的延遲時間取決於基於時鐘速度的硬件/軟件中斷。

如果您想了解Linux上的實現方式，請檢查POSIX標準。上信號

大信息：

http://www.gnu.org/software/libc/manual/html_node/index.html#toc_Signal-Handling

當產生信號時，它變得未決。正常情況下，它仍然在 待處理很短的時間，然後是交付到 進程信號。但是，如果這種信號是 當前被阻止，它可能會無限期地保持懸而未決 - 直到信號 是暢通。一旦暢通，它將立即交付 。

另一個摘錄：

當信號被傳遞，無論是立即或長 延遲之後，對於該信號的指定的動作取。