“interrupted system call”（eintr）是linux系统调用因信号中断而提前返回的常见现象，并非真正错误，而是内核通知程序信号已到达。1. 最常见的处理方式是重试系统调用，适用于如read()、write()等可安全重复执行的调用；2. 对connect()、select()、poll()等复杂调用需谨慎处理，可能需要关闭连接后重新开始或调整超时参数；3. 可通过sigprocmask()屏蔽信号或使用sa_restart标志自动重启被中断的调用；4. 多线程中应使用pthread_sigmask()控制信号接收或指定专门线程处理信号；5. 在非关键任务中可选择忽略eintr，但需确保不影响程序正确性；6. 测试可通过kill()、alarm()或strace工具模拟信号并验证处理逻辑是否符合预期。正确理解并处理该问题能显著提升linux应用程序的健壮性。
理解并优雅地处理“Interrupted system call”错误，是编写健壮Linux应用程序的关键。
什么是”Interrupted system call”以及它为什么会出现？
“Interrupted system call”错误（通常表现为errno等于EINTR）发生在Linux系统调用执行期间，接收到一个信号（signal），导致系统调用提前中断。这并不是一个真正的错误，而是Linux内核通知应用程序“嘿，我收到了一个信号，打断了你的系统调用”。
为什么会出现？信号可能是用户通过Ctrl+C发送的中断信号，也可能是系统内部的其他信号，例如定时器信号。理解这一点至关重要，因为这决定了你如何处理它。
如何处理”Interrupted system call”错误？
最常见的处理方式是简单地重试系统调用。例如，在读取文件时：
ssize_t bytes_read; while ((bytes_read = read(fd, buffer, size)) == -1 && errno == EINTR) { // 重试 } if (bytes_read == -1) { // 真正的错误处理 perror("read"); } else { // 成功读取 }
这种方式简单有效，适用于大多数情况。但需要注意的是，并非所有系统调用都应该简单重试。
哪些系统调用需要特别注意？
某些系统调用，例如connect()，重试可能导致不可预测的结果。如果connect()在建立连接的过程中被中断，重试可能导致重复连接。在这种情况下，更好的策略是关闭socket，并重新开始连接过程。
另外，对于一些复杂的系统调用，例如select()或poll()，简单重试可能会导致逻辑错误。需要根据具体情况重新计算超时时间，或者重新设置监听的文件描述符。
如何避免”Interrupted system call”的频繁发生？
虽然无法完全避免信号的发生，但可以通过一些策略来减少”Interrupted system call”的频率。例如，可以使用sigprocmask()来临时屏蔽某些信号，在关键代码段执行完毕后再解除屏蔽。
此外，还可以考虑使用SA_RESTART标志。当使用sigaction()注册信号处理函数时，设置SA_RESTART标志可以告诉内核，在信号处理函数返回后，自动重启被中断的系统调用。但这并非万能药，某些系统调用仍然可能返回EINTR。
“Interrupted system call”与多线程有什么关系？
在多线程程序中，信号处理更加复杂。信号可能被传递给任何一个线程，这可能导致难以调试的问题。通常，建议使用专门的线程来处理信号，或者使用pthread_sigmask()来控制每个线程接收的信号。
除了重试，还有其他处理”Interrupted system call”的方式吗？
是的，在某些情况下，可以选择忽略”Interrupted system call”错误。例如，如果程序正在执行一些非关键的任务，并且允许被中断，那么可以直接忽略EINTR错误。但这需要仔细评估，确保不会影响程序的正确性。
如何测试”Interrupted system call”的处理？
测试”Interrupted system call”的处理是一个挑战，因为很难精确控制信号的发生时间。可以使用kill()函数向进程发送信号，或者使用alarm()函数设置定时器信号。还可以使用一些专门的测试工具，例如strace，来观察系统调用的执行情况。
