C 非阻塞系统调用是否可以中断？

我正在阅读（第21.5节）描述了阻塞系统调用如何被信号中断。这似乎意味着非阻塞系统调用不能被中断。这是真的吗？

这个问题基本上没有意义，因为在系统调用之前或之后的一个周期内，中断系统调用的信号与中断用户空间的信号之间几乎没有（可移植的）可观察的区别。

由于信号是异步的，因此SIGINT可能会在任何系统调用之外中断您的程序。我想知道一个程序是否可以在非阻塞系统调用被调用之后但在它返回之前被中断。我认为一般来说，任何系统调用都可以被信号中断。“非阻塞”只意味着进行系统调用不会改变进程的计划，但系统调用仍然必须运行，在这段时间内，信号可能会到达。是的，这对我来说是有意义的。也许这个例子提到阻塞系统调用只是因为它们更容易被中断，但这本书非常精确地描述了它是如何描述一切的，所以我觉得它实际上只是阻塞系统调用，但我没有证据证明这一点，我想你可以通过调用alarm（）来测试这一点安排一个信号，然后在紧循环中调用一些非阻塞调用，并检查信号处理程序中的堆栈内容，检查系统callIt的返回值在编程时并不是毫无意义的；如果非阻塞系统调用可能被中断，程序员必须在默认情况下检查错误代码EINTR，在这种情况下，系统调用可能需要重新启动（正常和预期行为）。如果无法中断非阻塞系统调用，则无需进行此检查，失败的系统调用可能是致命的-假设所有非阻塞系统调用都无法中断，可能会导致不必要的致命错误。如果您的意图不是将中断视为实际错误，则根本不要启用它。这是一个虚假的意图，因为它有内在的种族条件。所以根本不要启用它。我问这个问题更多的是从理论的角度来理解Linux内核，但是这是可能的workaround@dippynark：关于错误处理：如果任何函数调用的失败以不必要的方式影响程序的行为，处理文档中记录要设置的每个错误代码。@alk我知道如何处理/查找系统调用错误，我问这个问题是为了进一步了解内核如何工作-如果您使用的是信号处理程序，并且不知道程序何时会被中断，那么潜在返回的错误也不是您需要考虑的唯一问题，重入可能会导致问题