Unix/Linux编程：信号与exec()

exec()在执行时会将现有进程的文本段丢弃。该文本段可能包含了由调用进程创建的信号处理器程序。既然处理器已经不知所踪，内核就会对所有已经设置的信号重置为SIG_DFL。

不过，遭忽略的SIGCHLD信(忽略SIGCHLD能够组织僵尸进程的产生)号属于SUSv3中的特例。SUSv3中没有规定是继续让遭忽略的 SIGCHLD 信号保持被忽略状态，还是将对其处置重置为 SIG_DFL，而不同系统中采取的策略不同。这就意味着，对于忽略SIGCHLD的程序而言，要哦最大程度的保证可移植性，就应该在调用exec()之前执行signal(SIGCHLD, SIG_DFL)。此外，程序也不应当假设对SIGCHLD处置的初始设置是SIG_DFL 之外的其他值

老程序的数据段、堆、栈栈悉数被毁，这也意味着通过signalstakc()所创建的任何备选信号栈都会丢失，由于exec()在调用期间不会保护备选栈，孤儿也会将所有信号的SA_ONSTACK位清除掉

在调用exec()期间，进程信号掩码以及挂起起（pending）信号的设置均得以保存。这一特性允许对新程序的信号进程阻塞和排队处理。不过，SUSv3 指出，许多现有应用程序的编写
都基于如下的错误假设：程序启动时将对某些特定信号的处置置为 SIG_DFL，又或者并未阻塞这些信号。（特别是，C 语言标准对信号的规范很弱，对信号阻塞也未置一词，所以为非 UNIX系统所编写的 C 程序也不可能去解除对信号的阻塞。）为此，SUSv3 建议，在调用 exec()执行任何程序的过程中，不应当阻塞或忽略信号。这里的“任何程序”是指并非由 exec()的调用者所编写的程序。至于说如果执行和被执行的程序均出自一人之手，又或者对运行程序处理信号的手法知根知底，那自然又另当别论