- 信号什么时候被处理？
当用户进程从用户态经历内核态，返回用户态的时候，信号会在返回用户态前被处理。
.png)
- 如果有多个信号待处理，处理过程是怎样的？
当经历1中所说的“从内核态返回用户态”时，如果有多个信号待处理，则需要选择优先级越高（信号编号越小，除去SIGKILL不不能被阻塞，忽略，以及为其设置特定的处理函数）的信号进行处理。如果该选择的信号在一个时间片中没有处理完，则会根据进程当前的屏蔽集与当前待处理的信号集进行选择，选择此时未被屏蔽并且待处理的优先级最高信号执行其处理动作(如果有SIGKILL则必须直接执行SIGKILL)，对于下一个需要选择待处理信号的时刻也是如此。
当对某个信号没有设置处理动作的时候，按默认处理动作来处理。
在开始执行信号处理函数前，需要添加该种类的信号到屏蔽集中，在执行完后，恢复执行信号处理函数前的进程信号屏蔽集。
进程的所有sigaction相关内容在fork时都需要复制到子进程中。
对于类似于
SIGSEGV与SIGILL等之前会影响进程正常运行的信号，需要对内核做出相应的调整。对于默认终止进程的处理函数，规定都使用exit退出进程。
可以在符合POSIX标准的系统中进行相对应的测试，就行为而言，任务要求与其表现没有不同。
对于信号集的操作函数，如果参数非法，则需要跳过对于该部分数据的操作,返回-1即可。这里需要注意类似于
sigxxset，sigprocmask，sigaction与kill的不同。检查编译时出现的warning以及是否开启
MOS_PROFILE=release,代码在debug与release下的行为表现应该为相同。如果在release环境下没有触发SIGSEGV等异常，可能是由于release使用的O2优化会优化掉不使用的变量，诸如int a = *(int*)0x0;，如果后续没有使用a变量的话，是会被优化掉的。在测试时会替换掉所有的Makefile与mk文件，对于
user/lib下的源文件，是通过user/include.mk文件指定编译的，所以不能新增文件，而对于默认编译文件夹内所有源文件的源文件夹则可以随意添加源文件。如果PCB出现了异常值，请参考「Sigaction 挑战性任务」为什么进程控制块会变成预期之外的值？（存档）。
将会在spoc上开放挑战性任务文档提交通道。