今天在看《深入理解計算機系統》第8章的內容時,對於圖8-31的**有一些疑惑.
為什麼會是阻塞第二個訊號,自己在ubuntu14.04(核心為linux3.13.0-24)上敲了一遍**
#include#include#include#include#include#include#includevoid handler1(int sig)
int main()
for(i = 0; i < 3; ++i) }
printf("father love you!\n");
while(1);
exit(0);
}
最後的執行結果為
yk@yk-desktop:~/public$ gcc -o fork1 hello.c
yk@yk-desktop:~/public$ ./fork1
father love you!
hello from child 3225
hello from child 3226
hello from child 3227
handler reaped child 3225
handler reaped child 3226
證明了書上的結果是不正確的
我的理解為hadler在處理第乙個訊號時應該是將第二個訊號放在待處理列表,當第三個訊號到來時,由於不能同時將多個同型別訊號放在待處理列表,從而忽略第三個訊號。
而將handler函式優化之後產生了乙個很奇妙的現象//改為while迴圈處理訊號
void handler1(int sig)
由於父程序與子程序的處理順序不一致,幾次的執行結果都不同
yk@yk-desktop:~/public$ gcc -o fork1 hello.c
yk@yk-desktop:~/public$ ./fork1
father love you!
hello from child 3530
hello from child 3528
hello from child 3529
handler reaped child 3530
handler reaped child 3528
handler reaped child 3529
^cyk@yk-desktop:~/public$ gcc -o fork1 hello.c
yk@yk-desktop:~/public$ ./fork1
hello from child 3538
father love you!
hello from child 3539
hello from child 3540
handler reaped child 3538
handler reaped child 3539
handler reaped child 3540
^cyk@yk-desktop:~/public$ gcc -o fork1 hello.c
yk@yk-desktop:~/public$ ./fork1
hello from child 3551
father love you!
hello from child 3553
hello from child 3552
handler reaped child 3551
handler reaped child 3553
handler reaped child 3552
真有意思~
linux訊號 阻塞訊號
1.訊號在核心中的表示 我們知道了訊號產生的各種原因,而實際執行訊號處理的動作,叫做訊號遞達 delivery 訊號從產生到遞達之間的狀態,稱為訊號未決 pending 程序可以選擇阻塞 block 某個訊號。被阻塞的訊號產生時將保持在未決狀態,直到程序解除對此訊號的阻塞,才執行遞達的動作。注意,阻...
Linux 阻塞訊號
linux中訊號產生的原因大致有一下三種 鍵盤中斷 命令發出 異常產生中斷 但歸根結底,這些訊號其實都是最終有作業系統發出的。常見的對訊號的處理,無外乎以下三種 忽略終止該程序 自定義行為 對訊號的處理動作叫做訊號遞達,在訊號由產生到遞達的過程中還有一種狀態叫做未決。即訊號雖產生,但是未被處理。這個...
訊號的阻塞
訊號的阻塞就是讓系統暫時保留訊號留待以後傳送。注意 不是不傳送,而是延遲傳送 一般情況下訊號的阻塞只是暫時的,只是為了防止訊號打斷敏感的操作。1 訊號集 所有的訊號阻塞函式都使用稱作訊號集的資料結構來表明受到影響的訊號。每乙個操作都包括兩個階段 建立訊號集,傳遞訊號集給特定的庫函式。下面說明訊號集和...