understanding the linux kernel中关于信号有一点没看懂

iterator

这是书上讲到signal_wake_up()函数时的一段:
If try_to_wake_up( ) returned 0, the process was already runnable: if so, it checks whether the process is already running on another CPU and, in this case, sends an interprocessor interrupt to that CPU to force a reschedule of the current process (see the section "Interprocessor Interrupt Handling" in Chapter 4). Because each process checks the existence of pending signals when returning from the schedule( ) function, the interprocessor interrupt ensures that the destination process quickly notices the new pending signal.

"Because each process checks the existence of pending signals when returning from the schedule( ) function"?为什么说的是从schedule()返回时检测pending signal.不是从中断处理中返回检测吗?和schedule有什么关系呢?

xpl

这个说的是针对当前收到信号的进程来说的。
例如：
wait_ ....

schedule()

当schedule返回的时候，有可能是由于收到信号返回的，所以这个时候要检查一下。

iterator

但是作者说的中断好像是针对其他CPU上正在运行的程序说的,并不会有从schedule返回的情况.

flw2

确实和schedule 没关系
这里处理器中断的函数什么也不干，重新调度就等中断返回了

xpl

sorry， 没仔细看。

xpl

使另一个cpu产生中断以后，另一个cpu简单的从中断返回.  在返回的时候会do_singnal

在这里返回的时候会重新调度吗？

这部分code我刚才看了一下，没有找到哪里设置了need schedule

iterator

我也没找到,所以不理解作者的意思

flw2

我也没有找到，即使有，和schedule也没什么关系
而且该函数主要目的是别让对方马上响应信号，所以给个机会

zx_wing

确实没什么关系，唯一的可能是因为wake up用的IPI是smp_reschedule_interrupt。
linux中只有3种IPI，最简单的就是smp_reschedule_interrupt，它把目的CPU拉入中断再返回，如果设置了need schedule就可能引起重调度。
这里为了让对方相应信号，同样用IPI把CPU拉到内核态，目的就和flw2说的一样。我想提到scheduler可能是因为这个IPI可能引起重调度，但在scheduler返回的时候同样会响应pending的信号。

xpl

原帖由 zx_wing 于 2008-8-15 16:04 发表
确实没什么关系，唯一的可能是因为wake up用的IPI是smp_reschedule_interrupt。
linux中只有3种IPI，最简单的就是smp_reschedule_interrupt，它把目的CPU拉入中断再返回，如果设置了need schedule就可能引起重 ...

问题是如果没有设置need schedule， 不会产生重新调度的，只会递交未决信号。

感觉这个和schedule扯上关系有点牵强。