对跨进程发送信号的流程理解，请达人指点
本帖最后由 Huntsmen 于 2013-09-13 00:29 编辑在看APUE书时，线程、信号章节有这么一句话：
进程中的信号是递送到单个线程的。如果信号与硬件故障或定时器超时相关，该信号就被发送到引起该事件的线程中去，而其它的信号则被发送到任意一个线程。
对于这个任意，有点不是很明白，下面是我的个人理解，请达人帮忙看看理解的对不对
为了叙述方便，假设如下场景：
进程A有2个线程，记为A1、A2，
进程B有3个线程，记为B1、B2、B3;
跨进程发送信号是不能指定接收线程的，信号只能发送到目标进程，既每个进程有一个总的公共信号队列，然后进程下的各个线程有一个自己的私有信号队列，当线程A2给进程B发送信号时，信号是先放到进程B的信号队列中，然后内核再来看线程B1、B2、B3的sig mask，然后将信号交给没有屏蔽该信号的线程的私有信号队列中；
任意的理解就是对于发送进程A而言，它并不知道进程B中各个线程的sig mask情况，最终接收线程是B1、B2、B3都有可能，所以是任意的；
但是对于接收进程B而言，假设B1、B2、B3中只有B2没有屏蔽该信号时，信号是肯定发送到B2，但是如果B1、B2、B3都没有屏蔽该信号，那内核会随机的选一个线程来收信号来执行？
如果是同进程内的发送信号，是可以指定接收线程的，比如B2可以直接给B3发送信号，信号是直接放在了B3自己的信号队列中的？ 说了那么多, 懒得看.
信号处理函数是进程共享的, 信号掩码是线程独有的. 比如2个信号的mask一样，都在sigwait，当信号到达的时候，是由哪个线程被唤醒来执行这个signal handler呢？ 回复 1# Huntsmen
linux多线程和信号处理这块本身就有问题，不同版本的内核和glibc版对于这样的行为需要一一测试，因为linux的线程库标准化的时间也不长。要想可靠的使用sigwait，应该在所有不需要处理指定信号的线程中block指定的信号（最安全的作法），因为信号本身是基于进程的，否则会出现不知道哪个线程处理相应信号的情况，而且posix标准也没有保证调用sigwait的线程可以接收到指定的信号。在linux系统上默认情况下，信号将由主进程接收处理，就算信号处理函数是由子线程注册的， 在Linux中的posix线程模型中，线程拥有独立的进程号，可以通过getpid()得到线程的进程号，而线程号保存在pthread_t的值中。而主线程的进程号就是整个进程的进程号，因此向主进程发送信号只会将信号发送到主线程中去。如果主线程设置了信号屏蔽，则信号会投递到一个可以处理的线程中去（何为可以处理的线程这个规则就由操作系统实现去处理）。
Signal handling in LinuxThreads departs significantlyfromthePOSIX
standard. Accordingtothestandard,‘‘asynchronous’’(external)
signals are addressed to thewholeprocess(thecollectionofall
threads), which then delivers them to one particular thread. The thread
that actually receives the signal is any thread that does not currently
block the signal.
InLinuxThreads, each thread is actually a kernel process with its own
PID, so external signals are always directed to one particularthread.
If,forinstance,anotherthreadisblockedin !sigwait! on that
signal, it will not be restarted.
回复 4# myworkstation
谢谢解答，非常感谢
页:
[1]