前言：閱讀的時候如有不懂的的地方，可以看我之前寫的詳解行程信號(信號的種類、產生、注冊、注銷以及信號的各種處理方式)(一)

1. 信號的捕捉流程

在講信號的捕捉流程的時候，我們需要首先明確的一個問題是：信號的注冊，是否與作業系統所維護的行程PCB有關？

在上一篇文章中也講了，信號的注冊實質是將tast_struct(PCB)結構體中的struct sigpending結構體變數，它所包含的sigset_t signal位圖中所對應的那個信號的位元位置為1，然后在sigqueue佇列添加一個sigqueue節點，因此，信號的注冊，是注冊在了行程的PCB中，是與作業系統的PCB直接打交道的，

1.1 捕捉流程

要想清楚信號的捕捉流程，我們還得搞清楚的一個問題是信號是什么時候進行處理的？

首先需要知道的是信號的處理是在內核態完成的，就拿printf()函式來說把，他首先是一個庫函式，一旦呼叫，就會呼叫里面的系統呼叫函式，進而切換到內核態，完成相應的作業，然后再將相應的結果回傳至用戶態，

那么當從內核態切換到用戶態的時候，就一定會呼叫do_signal函式來處理行程所收到的信號，

do_signal函式會對所收到的函式做如下操作：(捕捉流程)

• sig位圖中有信號注冊，則執行信號注銷的邏輯
• sig位圖當中沒有信號的注冊，則直接回傳用戶態，

系統呼叫不會觸發信號佇列的處理,在每次由核心態切換到用戶狀態時,內核都會發起信號佇列處理，

1.2 處理信號(信號的注銷)

上一篇文章也講過，處理信號有三種方式，分別是默認處理方式、忽略處理方式 和 自定義處理方式，

默認處理方式和忽略處理方式都是直接在作業系統內核的代碼中完成的，

自定義處理方式是呼叫程式員自己定義的函式，那么若按自定義處理方式處理信號，其處理的流程如下：

• ① 在用戶態執行程式員自定義的函式
• ② 呼叫sigreturn函式再次回到作業系統內核
• ③ 再次呼叫do_signal函式判斷是否有信號注冊，如果還有就繼續轉去處理該信號
• ④ 呼叫sys_sigreturn函式回到用戶態去執行代碼

那么問題來了：什么時候進入作業系統內核？

• 呼叫系統呼叫函式
• 呼叫C庫函式（C庫函式的內部也是呼叫了系統呼叫函式）
• 記憶體訪問越界、訪問空指標

1.3 小結(圖解)

還是用printf函式來舉例，假設我們信號處理的方式是自定義處理方式，那么它的處理流程如下圖：

1.4 用戶態和內核態(擴展)

• 熟悉Unix/Linux系統的人都知道，fork函式的作業實際上是以系統呼叫的方式完成相應功能的，具體的作業是由sys_fork負責實施，其實無論是不是Unix或者Linux，對于任何作業系統來說，創建一個新的行程都是屬于核心功能，因為它要做很多底層細致地作業，消耗系統的物理資源，比如分配物理記憶體，從父行程拷貝相關資訊，拷貝設定頁目錄頁表等等，這些顯然不能隨便讓哪個程式就能去做，于是就自然引出特權級別的概念，顯然，最關鍵性的權力必須由高特權級的程式來執行，這樣才可以做到集中管理，減少有限資源的訪問和使用沖突，

• 對于 Unix/Linux來說，只使用了級特權級和3級特權級，也就是說在Unix/Linux系統中，一條作業在級特權級的指令具有了CPU能提供的最高權力，而一條作業在3級特權級的指令具有CPU提供的最低或者說最基本權力，

• 現在我們從特權級的調度來理解用戶態和內核態就比較好理解了，當程式運行在3級特權級上時，就可以稱之為運行在用戶態，因為這是最低特權級，是普通的用戶行程運行的特權級，大部分用戶直接面對的程式都是運行在用戶態；反之，當程式運行在級特權級上時，就可以稱之為運行在內核態，

• 雖然用戶態下和內核態下作業的程式有很多差別，但最重要的差別就在于特權級的不同，即權力的不同，運行在用戶態下的程式不能直接訪問作業系統內核資料結構和程式，

• 當我們在系統中執行一個程式時，大部分時間是運行在用戶態下的，在其需要作業系統幫助完成某些它沒有權力和能力完成的作業時就會切換到內核態，

這里的內容參考自用戶態和內核態的概念區別這篇文章，想要詳細了解的可以查看這篇文章，

2. 信號的阻塞

首先我們需要知道的是信號的阻塞是不會影響信號的注冊，

2.1 信號阻塞在內核中的存盤表示及阻塞原理

首先我們來查看struct task_struct(PCB)結構體中關于信號阻塞的變數，sigset_t blocked

在上一篇文章中已經介紹了sigset_t是一個位圖，那么我們該如何用sigset_t blocked來表示信號的阻塞呢？圖解如下：

blocked位圖的作用是：阻塞某一個信號的處理，

也就意味著執行流進入到內核之后，呼叫do_signal函式判斷是否有信號需要處理的時候，發現某一個信號被注冊了，同時也是需要判斷blocked位圖中該信號所對應的位元位是否為1，

• 若為1：則暫時不進行處理（即暫時不進行信號的注銷）
• 若為0：則直接進行處理

2.2 信號的阻塞介面

2.2.1 sigprocmask函式

int sigprocmask(int how,const sigset_t* set,sigset_t* oldset)

引數：

• how：想讓sigprocmask函式做什么事情，（相當于fcntl函式中的cmd引數一樣）

• SIG_BLOCK：設定某個信號為阻塞狀態
• SIG_UNBLOCK：設定某個信號為非阻塞狀態
• SIG_SETMASK：設定新的blocked位圖

• set：使用set位圖去設定blocked位圖（注意是去設定，而不是去替換），并且它也分為兩種情況：

• 若how引數中設定為SIG_BLOCK引數(即設定為阻塞)，則需要進行按位或的操作，
  例如：block(new)= block(old) | set
• 若how引數中設定為SIG_UNBLOCK引數(即設定為非阻塞),則需要對set位圖取反,再按位與上blocked位圖
  例如：block(new) = block(old) & ~set
• 若how引數中設定為SIG_SETMASK引數，則直接去設定新的blocked位圖，
  例如：block(new) = set

回傳值：

• 0：成功
• -1 ：失敗

2.2.2 sigprocmask函式的代碼驗證

創建一個檔案test.c，在該檔案中我們利用sigprocmask函式將blocked位圖中全部設定為1，呼叫sigfillset(sigset_t* set)函式可以將位圖中所有的位都設定為1（即設定為滿），然后利用while死回圈來觀察其全部阻塞后的現象，

代碼如下：

#include <stdio.h>
#include <unistd.h>
#include <signal.h>

int main()
{
    sigset_t set;
    //設定set位圖為滿
    sigfillset(&set);
    //呼叫sigprocmask函式將所有信號都設定為阻塞
    int ret = sigprocmask(SIG_SETMASK,&set,NULL);
    if(ret < 0)
    {
        perror("sigprocmask failed");
        return 0;
    }

    while(1)
    {
        puts("It's test to  sigprocmask");
        sleep(1);
    }
    return 0;
}

運行結果如下：

根據我們代碼的邏輯，當前行程的所有的信號都被阻塞掉，不管你使用什么信號，按理來說都應該被阻塞掉，那么問題來了，我們該如何停止該行程呢？

作業系統為了防止這種情況的發生，將9號信號和19號信號設定為不會被修改，也不會被修改的狀態，

• 使用9號信號殺死行程（SIGKILL）

查看當前程式發現已經被殺死了

• 使用19號信號暫停行程（SIGSTOP）

查看當前程式發現已經被暫停了

注：這里暫停的程式，可以使用fg命令進行恢復

2.3 sigset_t信號集操作函式(擴展)

以下sigset_t操作函式均包含在#include<signal.h>頭檔案中，

①int sigemptyset(sigset_t *set);

初始化由set指定的信號集，信號集里面的所有信號被清空，

② int sigfillset(sigset_t *set);

呼叫該函式后，set指向的信號集中將包含linux支持的62種信號，

③ int sigaddset(sigset_t *set, int signum);

在set指向的信號集中加入signum信號，

④int sigdelset(sigset_t *set, int signum);

在set指向的信號集中洗掉signum信號，

⑤int sigismember(const sigset_t *set, int signum);

判定信號signum是否在set指向的信號集中，

3. 代碼驗證非可靠信號的注冊和可靠信號的注冊

可靠信號和非可靠信號的區別就是非可靠信號對多次相同的信號只注冊一次，而可靠信號對多次相同的信號可以注冊多次，

并且非可靠信號的信號值為1-31，可靠信號的信號值為34-64，

我們可以呼叫signal函式或sigaction函式，將接收到的信號自定義處理，然后將所有的信號均設定為阻塞狀態，再利用kill -[num] PID分別給程式發送5次2號信號，和5次40號信號，然后將所有的信號都恢復原樣，然后觀察其現象，

代碼如下：

#include <stdio.h>
#include <unistd.h>
#include <signal.h>

void sigcallback(int i)
{
    puts("It's test to verify signal");
}

int main()
{

    signal(2,sigcallback);
    signal(40,sigcallback);

    sigset_t set;
    //設定set位圖為滿
    sigfillset(&set);

    sigset_t oldset;
    //呼叫sigprocmask函式將所有信號都設定為阻塞
    int ret = sigprocmask(SIG_SETMASK,&set,&oldset);
    if(ret < 0)
    {
        perror("first sigprocmask failed");
        return 0;
    }
    
    getchar();

    ret = sigprocmask(SIG_SETMASK,&oldset,NULL);
    if(ret < 0)
    {
        perror("second sigprocmask failed");
        return 0;
    }

    while(1)
    {
        sleep(1);
    }
    return 0;
}

運行結果如下：

我們先來驗證一下2號信號的

①由于有getchar()的存在，程式現在正在等待用戶輸入，而陷入阻塞

②我們借此使用kill命令發送5次2號信號和5次40號信號，查看sigcallback函式的列印情況來驗證它們是否為非可靠信號和可靠信號

③給其輸入一個值，讓程式進行下去，查看程式這邊對應的狀況為：

說明2號信號為非可靠信號，且40號信號為可靠信號

4. volatile關鍵字

volatile關鍵字的作用是：使變數保證記憶體的可見性，

根據馮諾伊曼體系結構我們可以知道，一個變數要進行運算，首先要從記憶體中將變數發送至快取，然后再運送至暫存器，由暫存器移送至CPU進行相應的運算，

而gcc/g++都有編譯代碼的優化選項，當CPU在計算資料的時候，為了快，對已經從記憶體中拿出來的資料，不會從記憶體中獲取，而是直接從暫存器中獲取，

舉個例子來說就是：

int g_val = 1;
while(g_val <= 0)
	g_val--;

正常情況是g_val的值從記憶體移送至暫存器，然后由CPU進行減減操作，然后再由暫存器將該值回傳記憶體，從而結束回圈，

而若加上gcc優化選項，則CPU會直接從暫存器獲取值，而不是從記憶體中獲取，因此，當g_val - - 的時候，記憶體中g_val = 0，而暫存器中g_val的值為1，在運行時，CPU直接從暫存器中獲取值進行減減，因此，程式就會陷入死回圈，

但是，只要加了關鍵字volatile，就會規定編譯器只能從記憶體中進行獲取，就能很好的解決該類問題，這就是記憶體可見性的具體的含義，

gcc優化選項:-o0、-o1、-o2、-o3，優先級是由低到高，要使用就在編譯時加上該選項即可，例如gcc -o2 test.c