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