signal_pending函数解析

经常我们在睡眠的代码中 会看到这样的例子：

    if (signal_pending(current)) {

     ret = -ERESTARTSYS;

     return ret;

    }

    关于 -ERESTARTSYS 到底是什么意思? 

 

     -ERESTARTSYS表示信号函数处理完毕后重新执行信号函数前的某个系统调用.

也就是说，如果信号函数前有发生系统调用，在调度用户信号函数之前,内核会检查系统调用的返回值，看看是不是因为这个信号而中断了系统调用.如果返回值 -ERESTARTSYS,并且当前调度的信号具备-ERESTARTSYS属性,系统就会在用户信号函数返回之后再执行该系统调用

 

    这个过程，不必深究，你就知道上层的库函数 ，当收到 -ERESTARTSYS这个返回值后，对于linux来讲，会自动的重新调用这个调用就可以了。

至于

signal_pending( current )―――》检查当前进程是否有信号处理，返回不为0表示有信号需要处理。

情景分析：
1，当一个系统调用处于等待状态时，比如等待输入缓冲区不为空，此时产生了信号，这个信号仅仅是在该进程的thread_info结构中标识一下，就是所谓的“发信号”，然后唤醒进程的系统调用，系统调用醒来后，此时仅仅用signal_pending()检查一下是否有信号，这里，不处理信号的，当此时有信号，系统调用返回ERESTARTSYS，在从系统调用的返回用户空间时，会根据thread_info中信号标识位调用相应的信号处理函数，这里就是所谓的“接收信号”，对于Linux，上层库函数会根据系统调用的ERESTARTSYS返回值重启该系统调用，而对于Solaris则会让系统调用失败，在Linux中，重启的系统调用会再次检查缓冲区，为空，说明刚才的信号不是缓冲区有数据了的信号，继续等待，重复刚才的过程，不为空，就可以直接处理数据，系统调用正常结束
注：“发信号”仅仅是标识thread_info，系统调用醒来检查信号，仅仅是signal_pending()判断一下thread_info中是否有任何一个信号标识，真正的“接受信号”是从系统调用返回时，或者异常处理程序返回时，比如每次的时钟中断处理函数返回时，检查thread_info中具体哪个信号，调用相应处理程序
补：对于Solaris，上面的情况，read在等，缓冲区满了，唤醒read进程，不同通过我们这里所谈的“信号”

检测进程p是否有待处理的信号(p->thread_info->flags中TIF_SIGPENDING位是否置位)
-----------------------------------------------------
static inline int  signal_pending (struct task_struct *p)
{
 

   return unlikely(test_tsk_thread_flag(p, TIF_SIGPENDING));
}
#define TIF_SIGPENDING      2  



-----------------------------------------------------
static inline int test_tsk_thread_flag(struct task_struct *tsk, int flag)
{
    return test_ti_thread_flag(task_thread_info(tsk), flag);
}



-----------------------------------------------------
static inline int test_ti_thread_flag(struct thread_info *ti, int flag)
{  
    return test_bit(flag, &ti->flags);
}




检测addr的第nr位是否为1(addr右起最低位为第0位)
-----------------------------------------------------
static inline int test_bit(int nr, const volatile void * addr)
{  
    return (1UL &(((const int *) addr)[nr >> 5] >>(nr & 31) )) != 0UL;