当一个进程向另一个进程发送信号时，接收进程在什么情况下等待，直到它被重新安排运行？
在什么情况下安装的信号处理程序立即被调用？
提升信号的过程会产生多less开销，而不是直接调用相应的信号处理程序？
通过命令行恢复已停止的进程
如何closures文件？
我可以发送SIGCONT到正在运行的进程吗？
正确的方式来使用信号处理程序
在shell脚本中的信号处理
关于信号的传递，TLPI指出，当下一个任务被调度时，从内核模式切换到用户模式时，信号是“正常”传递的，或者当任务已经在运行时，“立即”信号（假定“立即”将不得不由先发一个中断，否则怎么会这样）。 那么，不管这意味着什么，它不是严格的约束，但是它与发生的事情非常接近。
您必须区分实时信号和“正常”信号，以及同步生成的“正常”信号，大部分时间是由于硬件事件（例如分段故障）和不是（它们是异步生成的）。
实时信号排队 ，正常信号不是 。 这意味着正常信号的实现很可能仅仅是一个像任务字一样的掩码。
产生一个“正常”信号意味着设置一个位，当操作系统接下来决定是否必须传送一个信号时，它将对字进行零检测，并且如果需要则指出设置了哪个位，并调用信号处理程序（如有的话）。
为什么需要知道这一点唯一的实际原因是因为有可能“丢失”信号。 如果在第一个传送之前产生两个或更多个信号，那么它仍然只有一个信号。
实时信号的实现显然要复杂得多（需要排队等待实现的长度）。
由于硬件事件（例如段错误）而发生的信号是同步生成的，就好像过程称为自身终止（章节22.4 TLPI）一样，即它们“立即”传送，原因有两个。 首先，做别的事情是没有意义的，其次，当陷阱处理程序返回时，已经有内核/用户切换。 所以交付总是“立即”无论如何。
基本上，信号是异步的。 当信号被接收时，它们依靠信号处理程序来执行代码，因为你永远不知道什么时候会由于诸如进程调度程序等因素。 发送信号的延迟是基于硬件/软件中断，这是基于时钟速度的。
如果你想知道在Linux上如何实现，请检查POSIX标准。
关于信号的很好的信息：
http://www.gnu.org/software/libc/manual/html_node/index.html#toc_Signal-Handling
当一个信号产生时，它变成待定 。 通常情况下，它只是在短时间内处于待决状态，然后交付给发出信号的进程。 但是，如果这种信号目前受阻 ，它可能会无限期地等待 – 直到这种信号被解除 。 一旦畅通，它将立即交付。
另一个摘录：
信号传送时，无论是立即或长时间延迟后，都会采取指定的信号动作 。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
