我正在为嵌入式 Linux 系统编写用户应用程序，并且我正在为设备使用诸如打开、关闭、读取、ioctl 等常用功能。现在，我阅读了有关 EINTR 的信息，表明该函数被信号中断，但我不确定其含义。在我拥有的所有示例程序中，有时它已经完成，例如ioctl()，有时它没有完成，例如读（）。所以，我有点困惑。
我最好什么时候检查 EINTR 并重复函数调用？
【问题讨论】：
查看签名：http://pubs.opengroup.org/onlinepubs/009695399/functions/sigaction.html
SA_RESTART
This flag affects the behavior of interruptible functions; that is, those
specified to fail with errno set to EINTR. If set, and a function specified
as interruptible is interrupted by this signal, the function shall restart
and shall not fail with EINTR unless otherwise specified. If the flag is not
set, interruptible functions interrupted by this signal shall fail with errno
set to EINTR.
默认情况下，您具有 SA_RESTART 行为，因此如果您不使用信号，则不必担心 EINTR。
【讨论】：
signal(7) 以获取特定于 Linux 的明确信息。
您的应用程序是事件驱动的吗？ （意思是它的主循环包括select()/epoll_wait()调用）。
在事件驱动的应用程序中，您可以阻止所有信号，并且仅在 pselect()/epoll_pwait() 调用期间解除阻止它们。这样，您的其余代码就不必处理 EINTR。
【讨论】：
我知道这个问题很老，但我认为还有更多要说的。要回答标题中的具体问题：基本上永远不会。
除了select 和poll 之外，EINTR 只有在您安装后才会发生（可能是错误/不了解如何使用sigaction，或者是因为您想要能够中断阻塞操作）中断信号处理程序。当函数以EINTR 失败时循环重试只会撤消该操作。这样做是 80 年代和 90 年代初到中期的一种旧反模式，当时许多操作系统都有错误，据报道在不符合要求的情况下会生成 EINTR，但这些错误早已不复存在。
有可能，即使在您希望能够用信号中断事物的应用程序中，有些代码的成功完成非常重要，以至于您不能将 EINTR 视为错误条件并返回在未完成操作的情况下发送给调用者。在这种情况下，安装重试循环可能是有意义的，但最好在操作期间屏蔽信号（至少是可能中断的信号）并在完成后取消屏蔽。
【讨论】：
select 和poll 在这里特别？我在其他 libc 调用中看到 EINTR，即 waitpid。
EINTR 仅用于“函数被信号中断”或类似的情况，其中 interrupted 仅定义为非-SA_RESTART 信号处理程序。然而，对于poll，它被定义为“在 poll() 期间捕获了一个信号”，与该信号是否是一个中断信号无关。
sigaction，它忽略了错误库集的恶意标志）。注意：库不应该在开始时设置信号处理程序，但应该允许调用者设置它们如果它愿意。
在使用 read() 等待来自命名管道的输入时，我遇到了类似的问题。
我在GNU libc documentation 中找到了原语的解释和有用的宏：TEMP_FAILURE_RETRY
例子：
TEMP_FAILURE_RETRY (read_return = read((int)example_fifo, buffer, (size_t)n));
if (read_return==-1){
fprintf(stderr, "reader.c: read_fifo: read(): %s \n", strerror(errno));
fflush(stderr);
}
【讨论】：