【Linux】进程通信

Shier833_Ww

已于 2023-04-20 23:27:49 修改

阅读量145

点赞数

分类专栏： Linux学习文章标签： linux 服务器运维

于 2023-04-20 23:18:54 首次发布

本文链接：https://blog.csdn.net/SHIE_Ww/article/details/130277815

版权

Linux学习专栏收录该内容

5 篇文章 0 订阅

订阅专栏

一、信号是什么

联系实际

区分信号和信号量：
- 信号与[[6.进程间通信(IPC)#3 信号量（只说原理）]]无任何联系，属于两套不同体系。
- 信号：属于通信范畴
- 信号量：属于用于互斥和同步通信体系的。
生活中的信号：红绿灯；烽火；线上购物商品；外卖等
信号：本质是一种通知机制，用户或操作系统通过发送一定的信号，来通知进程某些事件已经发生，你可以在后续进行处理

信号特点

①进程要处理信号，必须具备“识别”信号的能力(看到＋处理动作)
②程序员让进程能够“识别”信号==>进程内部提前规定了这个信号应该如何被处理。
- kill -9杀死一个进程，本质就是对进程发送了9号信号来杀死进程，此处“9”就是一个信号
③信号产生是随机的，产生时进程可能在忙其他事==>故信号的后续处理，可能并非立即处理
④会临时记录对应的信号，方便后续进行处理
⑤会在合适的时候处理信号
⑥一般而言，信号的产生相对于进程是异步的

信号如何产生

本质：通过键盘组合键向目标进程发送信号
- 如ctrl+c本质就是通过键盘组合键向目标进程发送2号信号 --> 进程退出
信号处理的常见方式：
- a.默认（每一种信号都有默认的处理动作，进程自带的、程序员写好的逻辑）
- b.忽略（将计算机中记住的信号忘掉）
  - 如：闹钟响了，但是仍不想醒来。
- c.自定义动作（捕捉信号）
  - 如：闹钟响了，默认是起床，但是可以自定义动作来想跳广播体操

常见信号

kill -lLinux中对应的所有的信号：普通信号和实时信号（标绿为相对常见）
- 共62个信号（没有32,33，没有0号信号）：[1:31]信号被称为普通信号；[34:64]信号中带有RT的称为实时信号
- 实时操作系统：有严格的时序，需要立马严格地响应、处理完成。
- 分时操作系统：基于时间片的轮转调度算法(一个时间片上的时间乘以用户数,前者一定,后者越多,响应时间就越长)的操作系统
  - 目前所用操作系统,分时操作系统居多
- 如：汽车中的车载操作系统，有些操作系统是Linux，也会参与我们的汽车的操作（如刹车）。若是分时操作系统，刹车进程没货的处理机的处理，就不会马上刹车；若是实时操作系统，刹车就会立即执行。
  1.SIGHUP挂起
  2.SIGINT：中断/终止进程
  3.SIGQUIT：退出
  5.SIGTRAP和6.SIGTRAP：终止
  8.SIGFPE：浮点不透？
  9.SIGKILL：捕捉信号9号信号
  10.SIGUSR1：用户自定义信号
  11.SIGSEGV：段错误对应的错误
  13.SIGPIPE：向已关闭的管道中写入可能会出错误
  14.SIGALRM：闹钟
$ kill 7 signal
- value：认识信号的编号
- action：默认处理行为 ==> 信号对应的动作
  - Term：终止。 70%上的信号，被进程收到就是默认终止该进程
  - Core：终止且发生核心转储
    - 回顾核心转储介绍：[[4.Linux进程控制#core dump 标志：是否发生了核心转储。]]
  - Ign：忽略
  - Cont：继续

组合键如何变信号？

键盘的工作方式：中断 ==> 故能识别组合键
过程：OS解释组合键 ==> 查找进程列表 ==> 找到前台运行的进程 ==> OS写入对应的信号到进程内部的位图结构中

信号如何被进程保存？

采用位图的方式：
- 信号编号？ ==> 用unsigned int中的第几位表示；
- 是否产生？ ==> 用对应比特位0/1表示
- 如0000 0100表示第三个信号产生
信号位图字段是保存在进程PCB内部（task_struct）的,而task_struct是内核数据结构（操作系统内的数据结构），故只有操作系统才有资格修改内核数据结构。==> 即，信号产生方式多种，但都是操作系统发的（仅有OS有资格修改PCB内部的相关字段）
信号发送的本质：OS向目标进程写信号，即OS直接修改PCB中指定的位图结构，完成“发送”信号过程。

中断概念

计算机组成学科中相关中断概念

硬件：
- ①中断设备
- ②硬件单元（如8259）
- ③CPU的针脚
软件：
- ①中断向量表
- ②上下文线程保存和线程恢复

信号如何从硬件到软件？

前提：每一个设备都有对应的中断编号（简称中断号），中断号可理解作数组下标。==> 整个过程类似函数指针数组这样的概念。
①中断表和软件的对应，即用函数指针数组的方式和一张表来对应。当对应的某设备一旦触发了中断，就会通过硬件的方式，向计算机中（如CPU某些针脚上）发送对应的中断信息。
②中断信息对应的中断号就以硬件方式写入到特定的寄存器当中。
③操作系统就能够识别到对应寄存器内部的中断号，就可根据中断编号查找内置相关的中断处理方法。
④调用中断处理方法，完成从硬件到软件的行为

中断的分类

①网卡中断
- #待补充学习网络时候，会再把中断拿出来，帮助同学们做一个有完整性认知
- 网卡当中发送、接收消息时，硬件上先收到消息，软件上操作系统是如何得知有数据了吗？其实也是中断去处理的
②时钟中断
- 在计算机中，除了外设（包括网卡、键盘等）设备会触发中断，还有一类中断叫做时钟中断。
  - 它的频率非常高频（基本上是纳秒级别），每隔一定时间就会向对应的计算机触发时钟中断，一旦触发，操作系统就必须得先处理时钟中断。
  - 相当于计算机中有个天然的机制，每几纳秒就向操作系统发送对应的输入中断，操作系统就必须先执行软件的一个处理，此时即可进行诸如进程调度、调度时间检查、上下文切换、识别标准输入、识别网络相关的数据等等用户行为。
- 操作系统即是采取此驱动方式–时钟中断。
  - 有的程序跑一遍就结束；有的程序它永远不退出，即主逻辑是个死循环（ #待补充往后学习网络时，网络服务器就是死循环，永不退出，除非挂了）。
  - 操作系统启动之后永远也不退出的，其也属软件，操作系统的本质就是个死循环地执行运作进程，它能周而复始的去做一件事情；
- 例子：
  - ①刷新：“文件从应用层把数据刷新到操作系统里，操作系统会自动去将数据刷新到外设” 当中“刷新到外设”，正是由于操作系统内部的内核级相关执行流，这些执行流被操作系统定期根据时钟中断来调度（执行对应函数指针数组里定的方法来调度。调度的可能是用户进程，也可能是内部线程或者其他执行流），最终定期完成刷新行为。但若触发后检测时发现进程的时间片没有到达，它就什么都不干。
  - ②CPU的主频：每秒内可以进行响应指令的一个条数。主频越高，响应中断的时间单元节点那么越短。正因此，操作系统自动会直接进行各方面调度切换、各种内存管理、文件管理，包括有些文件定期被清理等。

二、产生信号

1. 通过终端按键产生信号 →a.键盘

signal命令

#include <signal.h>
typedef void(*sighandler_t)(int);
sighandler_t signal(int signum,sighandler_t handler);

用途：通过回调的方式，修改对应的信号捕捉方法
signum：对哪一个信号进行捕捉
handler：函数指针类型的参数
- 对函数中传入函数指针==> [[指针进阶#8、回调函数]]
void(*sighandler_t)(int)：返回值是void，参数是int的函数指针
$ ulimit -a：查看当前环境中相关资源配置的问题。
mysignal相关使用：
- 分析点①：signal函数仅仅是修改进程对特定信号的后续处理动作，不是直接调用对应的处理动作。如果后续没有任何SIGINT信号产生，catchSig永远也不会被调用。每个特定信号的处理动作，一般只有一个，修改后默认的就会被覆盖。

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

using namespace std;

void catchSig()
{
    cout << "进程捕捉到了一个信号，正在处理中： " << signum << " Pid: " << getpid() << endl
}

int main()
{
	//signal一般是写在main函数开头
    //“ctrl+c”是2号信号SIGINT是键盘产生的
    //signal(SIGINT, fun);//a.可直接写名（推荐，可读性好）
     signal(2, fun); //b.也可写编号
     signal(SIGINT, catchSig); //分析点①
     signal(SIGQUIT, catchSig);//“ctrl+\”是3号信号SIGQUIT

     while(true)
     {
         cout << "我是一个进程，我正在运行..., Pid: " << getpid() << endl;
         sleep(1);

         int a = 100;
         a /= 0;//除0后会触发8号信号

         cout << "run here ...." << endl;
     }
     return 0;
}

core文件形成后的调试（事后调试）==> 主要仅展示core的应用

步骤1：查看是否已核心转储形成core文件
$ ll 
	core.11077
	……
步骤2：
$ gdb mysignal # 可执行文件
(gdb) core-file core.11077
步骤3:
# 会自动定位到终止的错误代码位置

2. 调用系统函数向进程发信号 → b.系统调用接口

理解:用户调用系统接口–>执行OS对应的系统调用代码–>OS提取参数,或者设置特定的数值–>OS向目标进程写信号–>修改对应进程的信号标记位–>进程后续会处理信号–>执行对应的处理动作

`kill`接口

用途：向指定进程发送指定信号

#include <sys/types.h>
#include <signal.h>
int kill(pid_t pid, int sig);//pid指定进程;sig指定信号

实现mykill

#include <iostream>
#include <string>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <signal.h>

using namespace std;
static void Usage(string proc)
{
	cout << "Usage:\r\n\t" << proc << " signumber processid" << endl;
}

// ./mykill 2 pid ==>三个参数
int main(int argc, char* argv[])
{
	if(argc != 3) //命令行参数argc不为3,就是传参错误
	 {
		 Usage(argv[0]);
		 exit(1);
	 }

     int signumber = atoi(argv[1]);//①发几号的信号:0是可执行程序名字,1是第一个选项(即"./mykill 2 pid"中的第二个参数)
     int procid = atoi(argv[2]);//②给哪个进程发信号

     kill(procid, signumber);//给谁发什么信号
     return 0;
}

`raise`接口

自己向自己发送指定信号

#include <signal.h>
int raise(int sig);

raise的应用

#include <iostream>
#include <string>
#include <unistd.h>
#include <sys/wait.h>
#include <stdlib.h>

using namespace std;

int main(int argc, char* argv[])
{
	cout << "我开始运行了" << endl;
    //调用方式①
    //sleep(1);
    //raise(8); // = raise(6) = kill(getpid(), 6)
    //调用方式②
    abort(); // 自己给自己发6号信号,通常用来进行终止进程(终止进程:exit/return/abort)
    
    return 0;
}

3. 由软件条件产生信号 → c.软件条件

信号的产生可能无关用户操作，有可能是系统内部一些特定条件不满足，操作系统就会自动识别，从而发送信号

管道读关,写继续

对于管道的读端不光不读,而且还关闭了,写端一直在写==>会导致写没有意义,OS会自动终止对应的写端进程,通过发送13号信号SIGPIPE的方式
- 验证流程:①创建匿名管道 ②让父进程进行读取,子进程进行写入;③父子可以通信一段时间(非必需);④让父进程关闭读端,并且进入waitpid()等待子进程,子进程只要一直写入即可 ⑤结果必然,子进程退出,则父进程waitpid即可拿到子进程的退出status ⑥提取退出信号
- 为什么发送信号? > 操作系统识别到管道(管道是通过文件在内存级的实现)读端关闭了却还在写这个问题>此情况为软件条件不满足==>故OS直接发送13号信号SIGPIPE
理解:
- a. OS先识别到某种软件条件触发或者不满足
- b. OS构建信号,发送给指定的进程

`alarm`函数

用途:设定一个秒级别的闹钟,告诉内核在seconds秒后给当前进程发送SIGALRM信号, 该信号默认处理动作是终止当前进程。

#include <unistd.h>  
unsigned int alarm(unsigned int second

测试CPU的计算能力：验证1s之内，共会进行多少次count++

实现基本定时器功能

#include <iostream>
#include <string>
#include <unistd.h>
#include <sys/wait.h>
#include <stdlib.h>

using namespace std;

uint64_t count = 0;
// 实现基本定时器功能
void catchSig(int signum)
{
	cout<<"final count : "<<count<<endl;
	alarm(1);//每隔一秒就重设一个闹钟，就能不间断，避免一次性闹钟
}
int main(int argc, char* argv[])
{
	alarm(1); // 一次性闹钟：设定了一旦触发，就自动移除了
    // 1. 以下方式只能计算到1w+左右，原因：cout + 网络发送(Xshell是从云服务器远端发送至本地) ==> 这俩个都是阻塞式IO
    /*int count = 0; 
    while (true)
    {
        cout << "count:" << count++ << endl;
    }*/
    
    // 2. 单纯计算算力
    signal(SIGALRM, catchSig);
    while(true) count++;//纯计算，无IO

    return 0;
}

定时自动处理（如打印日志、刷新数据等）

#include <iostream>
#include <string>
#include <unistd.h>
#include <sys/wait.h>
#include <stdlib.h>
#include <vector>
#include <functional>

using namespace std;

typedef function<void ()> func;
vector<func> callbacks;

uint64_t count = 0;

void showCount()
{
    cout << "final count : " << count << endl;
}

void showLog()
{
    cout << "这个是日志功能" << endl;
}

void logUser()//定期查看用户是谁
{
    if(fork() == 0)//若是子进程
    {
        execl("/usr/bin/who", "who", nullptr);
        exit(1);
    }
    wait(nullptr);
}

// 此就可以用于处理数据自动定时刷新等任务
// void flushdata()
// {
// }

void catchSig(int signum)
{
    for(auto &f : callbacks)
    {
        f();
    }
    alarm(1);
}

int main(int argc, char* argv[])
{
	alarm(1); 
    signal(SIGALRM, catchSig);
    callbacks.push_back(showCount);
	callbacks.push_back(showLog);
	callbacks.push_back(logUser);
    while(true) count++;

    return 0;
}

4. 硬件异常产生信号 → d.硬件异常

理解除0问题（🔺）

①进行计算的是CPU硬件
②CPU内部是有多种寄存器，其中有个状态寄存器（软硬件的耦合方式）
- 状态寄存器(可看作位图)，其不进行数值保存，仅单纯保存本次计算状态。
- 状态寄存器有对应的状态标记位，如记录有无进位、有无溢出、结果正负、是否为零等等。
- 各标记位由硬件层面CPU设置，再由软件层面操作系统软件识别、自动进行计算完毕之后的检测。如果溢出标记位是1，OS立马就能识别到有溢出问题，并找到当前运行进程，提取其PID。而后OS完成信号发送的过程，进程会在合适的时候进行处理。
  - 为什么OS能立马找到？==>因为CPU内部的数据都是当前正在运行进程的上下文数据；而操作系统内核中有个指针test_struct*，该指针定义了一个current指向的当前正在运行的进程pcb。当进程被调度的时候，current指针内的内容也会load到CPU内其他相关的寄存器
- 因此除0错误属于硬件异常
③一旦出现硬件异常，进程不一定会退出(虽然一般默认是退出的)，但我们即便不退出，也做不了什么
④死循环的原因：寄存器中的异常一直没有被解决。
- 最好办法：打完日志后终止进程，自动释放上下文信息

理解野指针或越界问题

①越界、野指针问题在Linux中都可称段错误，无论哪种都必须通过地址,找到目标位置
- 读取未必报错，写入都会报错
②语言上面的“地址”，全都是虚拟地址
③在进行指针等访问时，需将虚拟地址转换成物理地址
- 虚拟→物理转化对效率要求很高，故采用硬件：页表（其中字段是二进制的，通过硬件形式对应到物理内存中）+内存管理单元MMU(Memory Manager Unit，属硬件)
④“野指针、越界”定是非法地址 --> 则MMU转化的时候,一定会报错 --> 操作系统就把MMU的报错转换成信号发送给进程
- 不是仅CPU存在寄存器，几乎任何外设和常见的硬件都可能存在寄存器。故MMU内部也有相关的寄存器或其他电路，从而能被CPU读取

using namespace std;

void handler(int signum)
{
    sleep(1);
    cout << "获得了一个信号: " << signum << endl;
    // exit(1);
} 


int main(int argc, char* argv[])
{
    //①除0异常
    signal(SIGFPE, handler);
    int a = 100;
    a /= 0;

    //②越界、野指针问题在Linux中都可称段错误==>对应11号SIGSEGV信号
    signal(SIGSEGV, handler);//捕捉到SIGSEGV就执行handler()

    int* p = nullptr;
    *p = 100;//p解引用后是指向0号地址，往没有写权限的0号地址写属于段错误

    while (true) sleep(1);

    return 0;
}

5. 对信号的总结:

所有的信号都有它的来源，但最终全部都是被OS识别、解释并发送的
- 以后再有新的信号来源，思考方向：它的场景产生的问题最终是如何被OS识别并解释的？
问题：
1. 上面所说的所有信号产生，最终都要有OS来进行执行，为什么？
  - 答：因为OS是进程的管理者
2. 信号的处理是否是立即处理的？在合适的时候
3. 信号如果不是被立即处理，信号需要暂时被进程记录下来，记录在PCB对应的信号位图当中
4. 一个进程在没有收到信号的时候，能知道应该对合法信号作何处理：程序员提前编写好了
5. 如何理解OS向进程发送信号？能否描述一下完整的发送处理过程？
  - 答：操作系统根据信号编号，修改对应位图中其特定的比特位，由0置1完成信号发送。

三、阻塞信号

1.信号其他相关常见概念

实际执行信号的处理动作，称为信号递达(Delivery)
信号从产生到递达之间的状态，称为信号未决(Pending)。
进程可以选择阻塞 (Block )某个信号。
- 被阻塞的信号产生时将保持在未决状态，直到进程解除对此信号的阻塞,才执行递达的动作.
- 区别忽略和阻塞
  - 忽略：已经递达并处理了这个动作，只是处理方式是忽略
    - 信号递达方式有3种：默认；忽略；自定义
  - 阻塞：未进行递达（根本不会进入信号处理流程）。若某信号被阻塞且永远不解除阻塞，那它永远都无法递达

2.信号在内核中的表示

Pending位图（Pending信号集） --> 整数

与信号未决概念有关
操作系统修改Pending位的信息：
- 比特位的位置代表信号编号；
- 比特位的内容（0和1）代表是否收到信号 ==> 0没有收到；1收到信号
- 如0000 0001：代表收到了1号信号；0000 0000：代表没有收到1号信号

handler处理方法 --> 函数指针数组

与信号递达概念有关

typedef（*handler_t)(int);
handler_t handler[32];

handler数组属于函数指针数组（起映射表的作用），数组的下标就是信号的编号
signal（signum,handler);：调用signal时，并非直接调用handler方法，而仅是将自定义的捕捉动作方法填入到handler数组下标里，真正的执行调用在后续才被实现。识别信号并根据对应动作执行的过程如下：

取到信号编号signal
handler[signal];
(int)handler[signal]==0;//执行默认动作，done
(int)handler[signal]==1;//执行忽略动作，done
handler[signal]();//当前两个动作都不满足时，才回去调用对应的方法

block位图（信号屏蔽字）

与阻塞有关
block位图与pending位图的异同：
- 【同】两者结构一样
- 【异】block位图中的内容代表：是否阻塞/屏蔽对应的信号；pending位图中的内容代表：是否收到信号

总结：一个信号被处理的过程

请添加图片描述

①OS向目标进程发送信号：即修改pending位图
②进程在合适时间处理信号：遍历检测pending位图，当找到为1的比特位时 ==> 先去block表查看当前信号是否被阻塞，若为1被阻塞则不处理当前信号；若为0，才进入handler表调用处理对应信号的方法
提高计算机学习认知
- ①结构②方案③算法
  - ==> 结构决定算法 ==> 如对于链表：头插、尾插、遍历、删除；而对于队列和栈具体算法的处理方式又有不同，但思想层面是相似的（结构决定了算法也就出来了）
- 明白学习一门学科，其究竟扮演着什么样的角色？
  - 数据结构扮演形成结构的过程（无论是结构体/指针/位图，都是结构）==> 语言层形成先描述的能力，而数据结构这门学科提供了再组织的能力，还需要编写匹配的算法（算法绝大部分都是基于某种结构的算法）
  - 为什么要构建如此的结构/对象？为什么以这种方式去构建呢？为什么要编写匹配的算法呢？
    - 一定是出于某种需求，需要解决某种问题（如进程排队问题、文件组织、编写内核级文件系统问题、编写某某文件管理系统等）
  - 学习要知道自己在学什么，知道所学的内容扮演的是什么样的角色，而不是单纯的把知识背记住==>提高计算机学习的认知，知识难度不降，但降低了学习成本

3.`sigset_t`

回顾以前学的操作系统类型：pid_t
- [[3.Linux进程概念#通过系统调用创建进程 – fork初始]]
基本上，语言会提供.h, .hpp和语言的自定义类型; 同时OS也会提供.h和OS自定义的类型
- 为什么OS要提供自定义的类型呢?
  - 因为要和OS提供的.h内部接口相对应(相当于系统调用接口). 有的接口不允许用户去传语言层的参数, 而是需要传结构体/位图等,而既然OS提供了对应接口,就必须也提供对应的类型
- 若对应的语言层某方法接口,涉及到硬件访问(如外设等),那么它底层100%必须要访问操作系统 ==> 语言层内部封装了系统调用 ==> 因此语言类提供的头文件(.h && .hpp)一定会包含OS提供的头文件(.h)以及OS自定义的类型
sigset_t属于位图结构, 也属于OS提供的一种数据类型
- 不必关心其细节,仅需知道它是个位图即可
- ① sigset_t不允许用户自己进行位操作, OS有提供对应的操作位图的方法 ==> [[7.进程通信#4 信号集操作函数]]
- ② user可以直接使用sigset_t类型,和用内置类型&&自定义类型没有任何差别
- ③sigset_t一定需要对应的系统接口来完成对应的功能,其中系统接口需要的参数,可能就包含了sigset_t定义的变量或者对象
由[[7.进程通信#2 信号在内核中的表示]]可见，每个信号只有一个bit的未决标志（0/1）和一个bit的阻塞标志，且并不记录该信号产生了多少次。
- ==> 未决和阻塞标志可以用相同的数据类型sigset_t来表示（并非是“存储”，存储的问题是由内核考虑的）
- sigset_t称为信号集（sigset_t位图结构，把所有信号放一起为集合的形式），这个类型可以表示每个信号的“有效”或“无效”状态。
  - 在阻塞信号集（即block信号集==>也有教材称其为信号屏蔽字Signal Mask）中“有效”和“无效”的含义是：该信号是否被阻塞；
  - 在未决信号集（即pending信号集）中“有效”和“无效”的含义是：该信号是否处于未决状态。

4.信号集操作函数

#include <signal.h>  
int sigemptyset(sigset_t *set);  //清空：全置0
int sigfillset(sigset_t *set);   //全置1
int sigaddset (sigset_t *set, int signo);  //将特定信号添加至信号集中（设置信号集中比特位）
int sigdelset(sigset_t *set, int signo);  //从信号集当中删除对应信号
int sigismember（const sigset_t *set, int signo);  //判定某个信号是否在信号集中

sigpending接口

#include<signal.h>
int sigpending(sigset_t *set);

用处：获取当前进程pending信号集中的所有位图结构 ==> 将操作系统OS内的数据通过sigpending接口拿给用户user
返回值：成功0；失败-1

sigprocmask接口

#include<signal.h>
int sigprocmask(int how,const sigset_t *set,sigset_t *oldset);

作用：检查并更改block信号字
返回值：成功0；失败-1
各参数说明
- int how可选值如下：
  - SIG_BLOCK：set包含要添加到当前信号屏蔽字的新信号 ==> mask = mask|set
  - SIG_UNBLOCK：set包含了要从当前信号屏蔽字中解除阻塞的信号 ==> mask=mask&~set
  - SIG_SETMASK：设置当前信号屏蔽字为set所指向的值 ==> mask = set
- sigset_t *oldset：输出型参数，用于返回旧的信号屏蔽字。
  - 若没需求，可直接设为nullptr
  - how参数的三种可选值，均是对原始进程的信号屏蔽字做更改，而*oldset参数是给原信号屏蔽字做备份，以备对旧信号的不时之需

5.编码验证

验证思路：

//makefile文件
mysignal:mysignal.cc
	g++ -o $@ $^ -std=c++11 -g
.PHONY:clean
clean:
	rm -f mysignal

①若我们对所有的信号都进行了自定义捕捉，是否旧写了一个不会被异常或者用户杀掉的进程？
- 不是，OS的设计者也考虑了。9号信号是无法被自定义捕捉的，就是用于避免该情况。

//mysignal.cc文件
#include <iostream>
#include <signal.h>
#include <unistd.h>

void catchSig(int signum)
{
    std::cout << "获取一个信号: " << signum << std::endl;
}

int main()
{
    for(int sig = 1; sig <= 31; sig++) signal(sig, catchSig);

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

②若我们将2号信号block，并且不断地获取并打印当前进程的pending信号集，而后突然发送一个2号信号 ==> 预计：可看到pending信号集中，有个比特位0→1
- 分析点①：默认情况下，恢复对于2号信号的block的时候，确会进行递达，但是2号信号的默认处理动作是终止进程，故需要对2号信号进行捕捉
- 分析点②：打印解除block和捕捉的顺序 --> 仅是打印语句放前放后的问题
- 我们可以同个sigpending获取pending 没有接口用于设置pending位图（所有的信号发送方式，都是修改pending位图的过程）
- 分析点③(void)n;：此语句是为了消除编译器的警告的习惯，比如定义了一个变量后面没有使用，编译器会提醒没使用。而将变量n强制转换为没有返回值的表达式，可以抑制编译器对变量的警告信息。
  - 此仅是个无意义的语句，写不写都一样。

#include <iostream>
#include <signal.h>
#include <unistd.h>
#include <cassert>

static void showPending(sigset_t& pending)
{
    for (int sig = 1; sig <= 31; sig++)
    {
        if (sigismember(&pending, sig))//在pending集合里
            std::cout << "1";
        else
            std::cout << "0";
    }
    std::cout << std::endl;
}

static void blockSig(int sig)
{
    sigset_t bset;
    sigemptyset(&bset);
    sigaddset(&bset, sig);
    int n = sigprocmask(SIG_BLOCK, &bset, nullptr);
    assert(n == 0);
    (void)n;
}

int main(){
	//0~4步实现对2号进程进行阻塞
	// 0. 方便测试，捕捉2号信号，不要退出 -- 分析点①
	signal(2, handler);
	// 1. 定义信号集对象
	sigset_t bset, obset;
	sigset_t pending;
	// 2. 初始化
	sigemptyset(&bset);
	sigemptyset(&obset);
	sigemptyset(&pending);
	// 3. 添加要进行屏蔽的信号
	sigaddset(&bset, 2 /*SIGINT*/);
	// 4. 设置set到内核中对应的进程内部[默认情况进程不会对任何信号进行block]
	int n = sigprocmask(SIG_BLOCK, &bset, &obset);
	assert(n == 0);//在release下不可用assert
	(void)n;//分析点③
	
	std::cout << "block 2 号信号成功... , pid: " << getpid() << std::endl;
	// 5. 重复打印当前进程的pending信号集
	int count = 0;
	while (true)
	{
	    // 5.1 获取当前进程的pending信号集
	    sigpending(&pending);
	    // 5.2 显示pending信号集中的没有被递达的信号
	    showPending(pending);
	    sleep(1);
	    count++;
	    if (count == 20)
	    {
	        //分析点①
	        std::cout << "解除对于2号信号的block" << std::endl;//分析点②
	        int n = sigprocmask(SIG_SETMASK, &obset, nullptr);
	        assert(n == 0);
	        (void)n;
	    }
	}
	
	return 0;
}

③ 若我们对所有的信号都block，是否就写了个不会被异常或者用户杀掉的进程？
- 9号信号无法被屏蔽，也无法被阻塞

#include <iostream>
#include <signal.h>
#include <unistd.h>
#include <cassert>

static void handler(int signum)
{
    std::cout << "捕捉 信号： " << signum << std::endl;
    // 不要终止进程，exit
}
static void showPending(sigset_t& pending)
{
    for (int sig = 1; sig <= 31; sig++)
    {
        if (sigismember(&pending, sig))
            std::cout << "1";
        else
            std::cout << "0";
    }
    std::cout << std::endl;
}

static void blockSig(int sig)
{
    sigset_t bset;
    sigemptyset(&bset);
    sigaddset(&bset, sig);
    int n = sigprocmask(SIG_BLOCK, &bset, nullptr);
    assert(n == 0);
    (void)n;
}

int main()
{
    for (int sig = 1; sig <= 31; sig++)
    {
        blockSig(sig);
    }
    sigset_t pending;
    while (true)
    {
        sigpending(&pending);
        showPending(pending);
        sleep(1);
    }
    return 0;
}

四、捕捉信号

信号产生后，信号可能无法被立即处理，在合适的时候
- ①什么时候是合适的
- ②信号处理的整个流程

1. 合适的时候

信号相关的数据字段都是在进程PCB内部，而PCB内部属于内核范畴
- 普通用户没有权力作检测，故若想检测当前信号是否被屏蔽，一定要处于内核状态
- 只执行自身代码时的状态，称作用户态
- ==> 故，合适时候：在内核态中，从内核态返回用户态的时候，进行信号检测和处理
为什么会进入内核态？
- 当进行系统调用、缺陷、陷阱、异常等
如何进入内核态？
- 在汇编语言层面上，有个终端编号int(汇编指令，取“中断interrupt”的前三个字母) 80，将代码的执行权限由我下达给操作系统，让操作系统去执行
- int 80：内置在系统调用函数中（可理解做系统调用函数内部就有int 80）

用户态和内核态

用户态是一个受管控的状态（如受访问权限的约束、资源限制）
内核态是一个操作系统执行自己代码的一个状态，具备非常高的优先级
回顾：进程地址空间[[3.Linux进程概念#五、程序地址空间]]
- 每个进程都有各自3~4G的进程地址空间，但所有进程都可看到同一个内核级页表，当需要执行系统调用的代码时，就会在进程地址空间中的内核地址空间找到对应系统调用的代码（过程如上图①）
  - [[3.Linux进程概念#地址空间]]
- 动态库的代码也是加载到各进程的进程地址空间里，当想执行动态库时，由于调用库也属于函数，则其也是在地址空间里调用，只不过库的代码用的是用户级页表（过程如上图②）
- 由①②可知：内核和进程切换的代码都是在所有进程的地址空间上下文中跑的。

进程从硬件到软件的整体原理

凭什么有权力执行OS的代码？==> 凭当前处于内核态，还是用户态。
- CPU寄存器有2套：1套可见；1套CPU不可见(自用的)
  - CPU中有一个寄存器为CR3 --> 表示当前CPU的执行权限：1表内核态，3表用户态
- 汇编指令int 80，将CPU中寄存器中3用户态改变至1内核态；而每个系统调用函数内部都存在int 80指令
故，进程从硬件到软件的整体原理如下：
- 当执行系统调用时（如调用open），它会先执行open中的int 80指令，将3用户态转换成1内核态，内核态允许访问，从而通过OS的权限审查，而后跳转到操作系统的内核地址空间，使用内核级页表，因此可以访问操作系统内的所有资源。
- 当系统调用结束后，系统调用结尾会将CPU内状态寄存器CR3中由1内核态再转换成3用户态后，跳转回代码继续执行后续的内容。

总结：内核态和用户态切换

为什么要从用户态切换到内核态？
- 用户需要通过软硬件资源达到自己的目的，但是访问软硬件资源必须通过操作系统（不允许跨层访问，因为内核态中执行的代码是属于优先级更高的代码，更重要的事情需要先被处理），也就必须从用户态转变成内核态
内核态与用户态的切换是如何做到的呢？
- 通过系统调用接口，访问内核。==> 系统调用接口又是通过调度，调度背后的逻辑是通过硬件层面上的时钟中断，在极短（每隔几纳秒）时间内就触发硬件来督促操作系统自行调度
- 具体的切换：CPU内存在寄存器，寄存器保存了当前的页表地址、当前进程PCB的地址，因此很快可以确认当前进程相关的信息，也就可以通过地址空间所表征的用户及内核的所有代码，直接访问即可。
  - [[7.进程通信#进程从硬件到软件的整体原理]]
为什么要从内核态切换到用户态？
- ①当前用户的代码仍未执行完（本进程未调度结束）
- ②当前用户层仍有若干进程未被调度（其余进程未调度结束）
- 计算机OS是为了给用户服务的，执行用户代码应为主，进入内核态仅是临时的状态，必须返回用户态继续执行用户的代码，从而给用户提供完整服务
为什么是从内核态返回用户态时进行信号检测处理，而不是从用户态刚进内核态就处理呢？
- 操作系统就是这么设计的。
- “ 接收到一个信号时，当前可能在操作优先级别更高、更重要的事情。所以信号还会被先pending ”==> 如何体现在处理优先级更高的事呢？ ==> 通过内核态返回用户态才进行信号检测处理体现。因为“从内核态返回用户态”时，说明已经把内核态所要做的事（优先级更高的事）处理完了，处理完优先级更高的事后才处理被pending的信号

2. 信号的捕捉

能否因为我们不系统调用，从而实现无法陷入内核呢？
- 不能，即便我们不系统调用，进程依旧会周期性地陷入内核
- 就如OS发现时间片到了，就会触发进程调度，即在当前进程的上下文执行调度函数（由于Linux底层使用C语言写的，故调度本质就是函数）。而调度该函数、执行这个方法之前，也必须要陷入，因此不论进程愿意与否，都必须陷入

handler的三种处理

①忽略：将pending清0（由1置0）即处理结束，而后无需返回用户态，并继续向后执行即可
②默认：大部分都是终止（将当前进程进入终止逻辑，不调度该进程，将PCB对应页表都释放了，也不需要返回用户态，而是继续向后执行）
- “终止不需要返回用户态”的话，若有的需求需要返回用户态执行呢？
  - 也有一些系统调用（如atexit），会用于在进程终止之前，帮你返回用户态，而后执行特定的方法
- 对于进程终止，那核心转储该怎么办呢？
  - 核心转储，即将内存中当前进程的相关数据转移到磁盘上（即IO），而在内核态是能读取当前进程的相关数据的。
  - 因此可以在退出之前，OS自动地把当前进程的核心数据，以当前用户身份来down到磁盘里，并且把进程pid以pid的方式来命名，最后再退出
- 可有时候也会遇到不退出的信号，是怎么回事呢？
  - 不退出的信号，比如“暂停”，对暂停的处理即，在内核态将当前进程的进程pcb状态由运行态改为T状态。==> 而后也不用恢复用户态，OS紧接着执行调度算法，将当前进程放入等待队列里，再重新选择进程去调度，因此进程就进入了暂停状态，就不回去了 ==> 直到下次由T状态变回R状态时，才能将该进程投入到运行队列里，重新调度
（handler处理中，在内核态里处理“忽略”和“默认”是容易理解、水到渠成的，“捕捉动作”相对不好理解）
③捕捉：捕捉意味着曾经已经设置了对该信号的回调处理，即在用户层代码中已经设置过了一个函数，该函数就是处理此信号的动作，执行完该函数，即完成了捕捉。
- 当在内核态转换成用户态之前，处理到一个执行handler捕捉方法的信号时，就要跳转到用户层，去执行对应的handler方法。
  - ①当前的状态？是内核kernal的身份。
  - ②以内核态，是否有能力执行用户层自定义的方法？==> 有
    - 操作系统若是愿意，它是能以内核态的身份去访问3~4G进程地址空间的代码、访问用户级页表，都是有能力做到的。证明有能力做到的例子如下：
    - a. 数据类型sigset_t传参时，是需要将用户层数据拷贝到内核的，若内核无法访问用户，它是无法完成拷贝的；
    - b. 对于很多系统调用，是需要将操作系统内的数据获取到，才能让我们在磁盘中读取到（如进行IO读取，调用文件read、write接口，其中数据都是操作系统先从外设磁盘读到自己的缓冲区中，而后再把数据从OS的缓冲区中拷贝到我们用户自定义的缓冲区。）
  - ③OS有能力帮用户执行对应的handler方法，但它并不愿意、也并不会执行。
    - 原因：若用户层方法中存在非法操作（如rm、scp…），此时以内核态的身份去执行，就会导致问题 > 操作系统不相信任何人（OS不相信任何user，才能保证自己的安全性，从而才能为user提供更好的服务）。> OS不以内核身份执行用户层方法，正是由于用户层方法是用户写的，无法保证方法的安全性，故不能用内核态执行用户层代码
    - 操作系统不相信任何人的体现：
      - a. 任何人想用操作系统的功能，必须通过系统调用，这是受管控的
      - b. 操作系统不会帮任何用户，执行任何一个用户层代码
- 故当处于内核态检测到信号要被捕捉时，从内核态返回用户层后，要执行用户层方法时，需要将当前状态从内核态转变成用户态，所有行为当前用户负责。
- 当以用户态身份执行完代码，即完成捕捉动作后，没有系统调用接口，用户态是无法返回内核态的。因此要通过执行特殊的系统调用sigreturn，从而再次进入内核态。再在内核态中，完成将pending比特位由1置0、恢复函数的栈帧结构等，而后返回main函数，继续向后执行，至此完成完整的信号捕捉动作。

完整的信号处理过程

🔺关键“∞”图：
1、信号捕捉调度变化的逻辑理解链
- ①当前正在执行的用户代码出于一些原因导致陷入内核
- ②在内核中执行完操作系统里的代码，准备返回用户态时做信号检测
  - 若当前有信号检测被判定没有被block，且handle是自定义的，就从内核态切换回用户态，执行用户对应的handler方法。
- ③当把handle方法执行完毕后，再通过特定的系统调用重新陷入内核，在内核中做一些比如收尾性工作。
- ④而后恢复到曾经对应main函数，或者用户态仍继续向后执行
2、信号捕捉身份转换的理解链
- ①从用户态进入内核态（从上到下）
- ②为了处理捕获动作，内核态返回用户态（从下到上）
- ③用户态处理完捕获动作后，再恢复到内核，执行收尾工作（从上到下）
- ④完成收尾后，再返回用户态继续执行后面的代码（从下到上）

3.信号的操作

sigaction函数

检查和更改系统动作的一个系统调用 ==> 捕捉信号
- sigaction函数在普通信号中能使用,在实时信号中也可使用
参数介绍
- int signo: 对应信号的编号
- const struct sigaction *act: 一种结构体[[7.进程通信#sigaction 结构体介绍]]，操作系统提供的数据类型.在C/C++中结构体类型名称和函数的名称允许是同样的(但并不建议这么处理).sigaction类型是一种输入型参数,此参数(sigaction类型的结构体)中包含你对该信号要怎么处理的回调函数
- struct sigaction *oldact: 返回对信号的旧处理方法,属于输出型参数.
返回值:成功返回0;失败返回-1及其错误码

#include <signal.h>  
int sigaction(int signo, const struct sigaction *act, struct sigaction *oldact);

`sigaction`结构体介绍

struct sigaction{
    void (*sa_handler)(int); //sa_handler方法即对应信号捕捉的回调函数
    void (*sa_sigaction)(int, siginfo_t *, void *);//×暂时不考虑
	sigset_t sa_mask; //√重点谈论
	int sa_flags; //×暂时不考虑
	void (*sa_restorer)(void);//×暂时不考虑
};

void (*sa_handler)(int);
- 将sa_handler赋值为常数SIG_IGN传给sigaction表示忽略信号；赋值为常数SIG_DFL表示执行系统默认动作；赋值为一个函数指针表示用自定义函数捕捉信号，或者说向内核注册了一个信号处理函数,
- 该函数返回值为void,可以带一个int参数,通过参数可以得知当前信号的编号,这样就可以用同一个函数处理多种信号。
- 显然，这也是个回调函数，并非被main函数调用，而是被系统所调用。
处理信号执行自定义动作时，如果在处理信号期间，又来了同样的信号，OS如何处理? ( 本质: 为什么要有block/信号屏蔽字? ==> 为了支持操作系统内处理普通信号，防止进行递归式处理；而我们主要让其在自己周期内只会调用一层，不会出现过多的调用层次)
- 当某个信号的处理函数被调用时，内核自动将当前信号加入进程的信号屏蔽字，当信号处理函数返回时自动恢复原来的信号屏蔽字。
- 这样就保证了在处理某个信号时，如果这种信号再次产生，那它会被阻塞到当前处理结束为止。

五、可重入函数

信号捕捉，并没有创建新的进程或线程
重入函数：一个函数在一个特定时间段内被多个执行流重复进入，此函数称为“重入函数”
- 若重入并不导致函数出现问题，称之为“可重入函数”
- 若重入导致函数出现问题，称之为“不可重入函数”
可重入函数和不可重入函数：属于函数的一种特征，并无好坏之分。
目前我们使用的90%函数，都是不可重入的，如果一个函数符合以下条件之一则是不可重入的:
- ①调用了malloc或free,因为malloc也是用全局链表来管理堆的。
- ②调用了标准I/O库函数。标准I/O库的很多实现都以不可重入的方式使用全局数据结构。

六、volatile关键字

我们无法假设别人的编译场景，编译器有时候会自动进行代码优化：
- VS2019用户很难看出其中的优化；
- 而gcc/g++有特定的优化级别，其有明显的优化选项可供设置。一般默认使用的是-O1，-O3是优化级别最高的。
- 编译器的优化是在编译阶段就优化好了
volatile关键字作用演示
- 结果说明：即使signal将flag从0置1，但程序依旧无法退出
- 原因说明：在下例中flag属于全局变量，内存中存储变量flag值（默认情况为0）。
  - 当代码正常执行时：CPU会从内存中读取flag数据（最初为0）到cpu寄存器（CPU中有很多寄存器，此处以edx为例）中，而后对其进行检测（即判断!flag）
  - 编译器优化情况：由于在main函数中仅有对flag做检测的语句（!flag），并无修改flag的语句。 ==> 于是在编译器优化里（-O3优化），编译器第一次将flag的默认值0放入edx后，再做while循环检测时，它自作主张仅在cpu里重复对第一次读取到的flag做检测。 > 可当信号来时（signal(2,changeFlag);），即使修改了内存中flag=1，cpu也并不再访问内存里flag，依旧检测的是首次读到的flag值，导致了数组二异性。> 故优化的存在，让cpu无法看到内存了
- 对问题的改进：对代码中可能被优化的字段（如下例中的volatile int flag =0;），就需要程序员显性地告诉编译器不要给它优化（如对于下例中的while(!flag);，必须去内存中访问 ==> 保持内存的可见性）

int flag =0;//volatile int flag =0;
void changeFlag(int signum)
{
	(void)signum;
	cout << "change flag:" << flag;
	flag = 1;
	cout<<"->"<<flag<<endl;
}

int main()
{
	signal(2,changeFlag);
	while(!flag);
	cout << "进程正常退出后：" << flag << endl;
}

volatile的作用：保持内存的可见性，告知编译器，被该关键字修饰的变量（如上例中的：volatile int flag =0;），不允许被优化，对该变量的任何操作，都必须在真实的内存中进行操作

七、SIGCHLD信号（选学了解）

回顾：[[4.Linux进程控制#1、进程等待的必要性功能]]子进程在退出后，父进程需要对其wait，否则会造成以下两点问题
- ① 产生僵尸进程，进而导致内存泄漏
- ② 父进程无法得知子进程的退出结果，即无法拿到进程的退出码、退出信号
而父进程处理子进程结束有两种方式：
- 阻塞：[[7.进程通信#1 父进程阻塞等待子进程结束]]
- 非阻塞：[[7.进程通信#2 父进程非阻塞查询是否有子进程结束等待清理 → 即轮询]]

1.父进程阻塞等待子进程结束

回顾：[[4.Linux进程控制#2、进程等待的方法]]
阻塞处理的不足：子进程若识别作未结束的状态，就会导致父进程阻塞等待子进程，就不能处理父进程自己的工作了。

2. 父进程非阻塞查询是否有子进程结束等待清理 → 即轮询

轮询过程：子进程在退出或暂停时，会主动地通过OS，向父进程发送17号SIGCHLD信号。
- 既然子进程在退出是主动发送了信号，为什么还会导致僵尸进程的存在（即为什么父进程还是没有释放处理它）呢？
  - 父进程没有处理子进程退出信号，是由于17号SIGCHLD信号默认动作是忽略（应用层忽略是什么都不做；在内核中，OS可能还会对忽略再做些工作）。
  - 区分应用层和OS级的“忽略”：[[7.进程通信#5、应用层和系统默认的“忽略”]]
- 只有Linux采用了 “子进程在退出或暂停时，会主动地通过OS，向父进程发送17号SIGCHLD信号” 的方案
非阻塞处理的不足及优势
- 不足：父进程在处理自己的工作的同时还要记得时不时地轮询一下,程序实现复杂。
- 优势：检测到退出子进程就回收，检测到没退出就下一个，不会被阻塞卡住
回收退出子进程的新思路：既然Linux采用了发送SIGCHLD信号的方式通知父进程，父进程就不必主动去等待子进程了，而是当子进程退出时，通过设置捕捉信号，在捕捉方法里对信号做回收，就能完成一套基于信号版的子进程回收

3. 验证子进程向父进程发送`SIGCHLD`信号

//证明子进程退出，会向父进程发送17号SIGCHLD信号
void handler(int signum)//父进程执行信号捕捉handler
{
	cout <<"子进程退出: "<< signum << endl;
	cout << "father pid: " << getpid() << endl;//若输出17号新号编码，则证明确实子进程退出发出了17号SIGCHLD信号

	//父进程进行信号捕捉，故可在此回收退出的子进程
	wait();//若有10个子进程都退出，则采用while(wait())
}

int main()
{ 
	signal(SIGCHLD, handler);//捕捉子进程退出发出的SIGCHLD信号
	if(fork() == 0)//子进程退出
	{
		cout<< "child pid: " << getpid()<<endl;
		sleep(1);
		exit(0);
	}
	while(true) sleep(1);//此处是否“exit(0);” ==> 取决于是否需要父进程退出 ==> 取决后面的代码需求
	……
}

//最后输出
// child pid: 27251
// 子进程退出: 17
// father pid: 27250

4. 信号版的子进程回收代码

为什么要遍历所有子进程？

子进程退出，父进程是会接收到子进程退出发送的SIGCHLD信号，但：
- ①父进程无法得知是哪个子进程退出；
- ②父进程无法得知所有进程里共有多少个子进程退出
- ==>故必须采用while去遍历所有的子进程
若一共10个进程，其中有5个子进程退出，当while循环出前5个都退出发送了SIGCHLD信号，那还要继续while循环第6个子进程吗？
- 要
- ①父进程无法站在上帝视角，得知共有几个子进程退出
  - 同时向父进程发送多个SIGCHLD信号，仅会接收到1个，其余可认为均丢失，因为：
    - a. SIGCHLD信号的bite位仅有1个，它并没有传达信号数量的信息。
    - b. pending位图里只有1个比特位表示收到某一个信号，故即使同一个时刻收到了多个SIGCHLD信号，实际上只收到了1个信号（操作系统只会保留一个），而剩下的4个信号可认为已丢失了
    - ▲但注意这是普通信号的特征，而对于实时信号是会把所有信号保留起来的
  - 故作为信号的处理者，即使此时收到了1个SIGCHLD信号，但其实并不能确定有几个进程退出，所以只能用while循环不断去读取。
- ②while循环的功能：回收+检测
  - 对于第6个进程仍需要继续检测，并非为了回收，而是检测
    - waitpid和wait本身除了回收，还可以检测子进程是否退出。==> 因为我们无法确定进程退出的数量是5个还是6个，故仍需通过while循环继续检测
  - 若6号进程检测到并没有退出，则此时的信号处理就会被阻塞在那，阻塞式地等待6号进程，导致主进程（相当于main执行流）的事就无法执行了==> 因此，考虑非阻塞遍历子进程

如何非阻塞遍历所有子进程？

方式①while循环+vector<int> pids数组：在fork时，采用vector<int> pids数组记录所有子进程pid，而后去非阻塞遍历所有进程，再在对应代码里对其进行捕捉检测，从而回收退出的子进程
方式②while( (id = waitpid(-1, NULL, WNOHANG))：waitpid中传入-1，效果等价于wait。作用是：我们可以等待任何一个退出的进程，不关心是哪个，但若是-1，操作系统就会去识别哪个进程退出了；若没有任何一个进程退出，调用-1也会导致阻塞

5. 应用层和系统默认的“忽略”

代码最终实现的目的：父进程又不想等子进程（即不关心子进程退出码，不在意其退出是否异常或其他），并且还想让子进程退出之后，系统直接自动释放、回收僵尸子进程
分析点①：应用层和系统默认的“忽略”程度是不同的
- 对于应用层中手动设置的“忽略”：属于用户明确告知内核了是直接忽略，并且遇到僵尸进程直接释放掉
- 操作系统级别的“忽略”：属于默认的动作，什么也不做，进程该僵尸就僵尸（操作系统拿不准是否要回收）

#include<iosteam>
#include<unistd.h>
#include<signal.h>
using namespace std;

int main()
{
	//手动设置对子进程进行忽略（应用层的忽略）
	signal(SIGCHLD,SIG_IGN);//分析点①

	if(fork()==0)
	{
		cout<<"child: "<<getpid()<<endl;
		sleep(5);
		exit(0);
	}

	// 非阻塞处理子进程退出，父进程能做自己的事
	while(true)
	{
		cout<<"parent: "<<getpid()<<"父进程执行自己的任务！"<<endl;
		sleep(1);
	}
}

Shier833_Ww

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
【Linux】进程通信

详细讲解Linux信号相关知识点，总体贯穿“信号产生→ 信号保存 → 信号处理”。从介绍信号是什么与信号的产生，到如何捕捉处理信号。同时拓展相关知识点，如volatile关键字及SIGCHLD信号等。
复制链接

扫一扫