转自：http://www.xuebuyuan.com/1470645.html
最近在工作中遇到了EINTR错误，感到比较困惑，几番研究之后，颇有心得和收获，特记录如下，便于以后查询，也给有同样困惑的朋友们提供一点借鉴。
我们经常在网络编程中会看到这样，当执行一个可能会阻塞的系统调用后，在返回的时候需要检查下错误码（if errno == EINTR），如果是这样的错误，那我们一般会重新执行该系统调用。所以经常的写法是：
repeat:
if(read(fd, buff, size) < 0)
{
if(errno == EINTR)
goto repeat;
else
printf("read failed");
}
但一般我们在读/写磁盘文件的时候却不太会判断这个错误，那我们到底什么时候该判断而什么时候又不要去判断呢？这是个问题。针对这个问题我特意做了一些测试。首先是读磁盘文件，测试代码如下：
#define _GNU_SOURCE
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <fcntl.h>
#include <signal.h>
#include <string.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/stat.h>
void hup_handler(int sig)
{
printf(".");
fflush(stdout);
}
int main()
{
int i = 0;
struct sigaction act;
const int buffSize = 1 << 27;
int allocated = 0;
char* buf = NULL;
act.sa_handler = hup_handler;
act.sa_flags = SA_INTERRUPT;
sigemptyset(&act.sa_mask);
allocated = posix_memalign((void**)&buf, getpagesize(), buffSize);
if (0 != allocated)
{
perror("posix_memalign error");
exit(1);
}
sigaction(SIGHUP, &act, NULL);
int fd = open("testfile", O_RDWR | O_DIRECT);
//for (i = 0; i < 1; ++i)
for (;
{
if (lseek(fd, 0, SEEK_SET) == -1)
{
printf("lseek failed: %s\n", strerror(errno));
}
if (read(fd, buf, buffSize) != buffSize)
{
printf("read failed: %s\n", strerror(errno));
}
}
}
代码中注册了信号SIG_HUP的信号处理函数，收到信号的时候应该会进入该处理函数。使用了O_DIRECT方式直接从磁盘读，然后运行该程序。在另外一个终端发送信号
while true; do pkill -HUP read; done
观察read进程，发现read确实进入了信号处理函数（终端输出了"......"）但是，程序并没有打印出“read failed”错误，这与我们的预期不太符合，测试发现调用write接口时，现象也一样。
为了进一步验证，我尝试去read终端设备，然后发信号，整个流程跟上面read测试基本相同，测试代码如下：
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <string.h>
#include <errno.h>
#include <unistd.h>
#include <signal.h>
#include <stdbool.h>
void int_handler(int signum)
{
printf("....\n");
}
int main()
{
char buf[128];
ssize_t ret;
struct sigaction oldact;
struct sigaction act;
act.sa_handler = int_handler;
//act.sa_flags = SA_INTERRUPT;
act.sa_flags = SA_RESTART;
sigemptyset(&act.sa_mask);
if(-1 == sigaction(SIGHUP, &act, &oldact))
{
exit(1);
}
bzero(buf, 100);
while(true)
{
ret = read(STDIN_FILENO, buf, 10);
if(-1 == ret)
{
perror("read terminal");
//printf("read error%s\n"), strerror(errno);
}
}
return 0;
}
编译运行该函数，然后在另外一个终端为其发送信号：
while true; do pkill -HUP read; done
然后观察发现，第一终端处理函数确实被执行了，然后read函数不断打印错误，“read terminal:Interuptible system call”。发现read函数确实在执行成功以前被信号中断了，返回EINTR错误。
这种情况在read socket也同样出现。那为什么read磁盘文件不会出现上面的情况呢？
为了理解各种原因，我们首先来看看linux的信号处理流程。
一般来说，信号处理函数会在进程执行系统或者库函数调用退出时刻被执行，也就是说，进程的信号处理是在系统调用从内核态返回至用户态之前被执行的，如果该进程收到了信号的话。对于一直处于RUNNING态的进程来说，会在系统调用执行完成后，返回用户态前夕执行信号处理函数。
但是，如果进程在内核态进行了状态转换，这时候处理流程就有点微妙的变化了。如由于等待某些事件的发生（最典型的IO等待），进程可能会从RUNNING状态转变为休眠状态，休眠状态的进程会被切换出CPU。但休眠状态有两种：第一是INTERUPTIBLE进程，第二种UNINTERUPTIBLE进程。第一种进程是可被信号唤醒的进程，第二种是不可被信号唤醒的进程，这就是问题的关键。对于INTERUPTIBLE状态的进程，一旦被信号唤醒后，会退出内核态执行，退出内核态之前执行信号处理函数。如果资源没准备好，那此时可能会设置错误码为EINTR。但是对于处于UNTERUPTIBLE状态的进程，该进程是不可被信号唤醒的，也就是说，当进程休眠时，会屏蔽所有的信号，直到它从休眠状态返回至RUNNING状态，执行完成后，返回上次执行的地方继续运行，然后退出内核态时候执行所有信号的处理函数。也就是说，这个状态的进程应该是不会被信号中断的，只会等到资源准备妥当时候才会被唤醒，这时候应该不存在会返回EINTR错误的情况。
为了验证这种情况，我们使用ps -aux查看了上述几种情况下进程所处的状态。首先是读磁盘，ps-aux发现其显示状态为D（即UNTERUPTIBLE），接下来读terminal，ps -aux显示其状态为S（INTERUPTIBLE）。
这就能解释上述两种情况显示的现象不一致的原因了。read磁盘的时候进程是处于UNINTERUPTIBLE状态，没法被信号唤醒，只能等到read到的数据准备好的时候被唤醒，这个时候再从内核态返回至用户态处理信号处理函数时，并不会出现EINTR错误。
而对于read读终端，情况则不一样，它处于INTERUPTIBLE状态，当被信号唤醒时，会直接退出内核态，此时应该提醒用户态资源并没有准备好，因此应该返回EINTR错误。以便用户态可以做出自己的决定。
备注：如果不想内核在系统调用返回EINTR错误，那么可以将信号处理函数的标记位设置SA_RESTART。