解析：signal_pending与返回-ERESTARTSYS

110 阅读 0 评论 73 点赞

我是靠谱客的博主高贵啤酒，最近开发中收集的这篇文章主要介绍解析：signal_pending与返回-ERESTARTSYS，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

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

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));
}