今天看Linux驱动时,发现一个erestartsys的返回,是在阻塞中看到的, ERESTARTSYS
ldd3说的也不是很清楚,后来会反复查阅,自己猜测在wake_up_interruptible的时候,这个时候被其他信号唤醒,由于不是本身
所唤醒的,这个时候,依然从我们的的系统调用中返回,但是上层在处理完其他信号后,还会再次调用我们这个系统调用。
摘自:http://blogold.chinaunix.net/u/22617/showart.php?id=391733
if (signal_pending(current)) {
ret = -ERESTARTSYS;
return ret;
}
关于 ERESTARTSYS 到底是什么意思? 通过下面的论坛可以了解一下。
http://bbs.chinaunix.net/thread-985689-7-9.html
这个过程,不必深究, 你就知道上层的库函数 ,当收到 -ERESTARTSYS 这个返回值后,对于linux来讲,会自动的重新调用这个调用就可以了。
, 这么写就可以了。
摘自:http://bbs.chinaunix.net/thread-985689-7-9.html
情景分析:
1,当一个系统调用处于等待状态时,比如等待输入缓冲区不为空,此时产生了信号,这个信号仅仅是在该进程的thread_info结构中标识一下,就是所谓的“发信号”,然后唤醒进程的系统调用,系统调用醒来后,此时仅仅用signal_pending()检查一下是否有信号,这里,不处理信号的,当此时有信号,系统调用返回ERESTARTSYS,在从系统调用的返回用户空间时,会根据thread_info中信号标识位调用相应的信号处理函数,这里就是所谓的“接收信号”,对于Linux,上层库函数会根据系统调用的ERESTARTSYS返回值重启该系统调用,而对于Solaris则会让系统调用失败,在Linux中,重启的系统调用会再次检查缓冲区,为空,说明刚才的信号不是缓冲区有数据了的信号,继续等待,重复刚才的过程,不为空,就可以直接处理数据,系统调用正常结束
注:“发信号”仅仅是标识thread_info,系统调用醒来检查信号,仅仅是signal_pending()判断一下thread_info中是否有任何一个信号标识,真正的“接受信号”是从系统调用返回时,或者异常处理程序返回时,比如每次的时钟中断处理函数返回时,检查thread_info中具体哪个信号,调用相应处理程序
补:对于Solaris,上面的情况,read在等,缓冲区满了,唤醒read进程,不同通过我们这里所谈的“信号”