EINTR背后的理由是什么？

Question

闲聊作为背景

EINTR是所谓的可中断系统调用可能返回的错误.如果在系统调用运行时发生信号，则不会忽略该信号。如果在没有SA_RESTART设置的情况下为它定义了一个信号处理程序，并且该处理程序处理该信号，那么系统调用将返回EINTR错误代码。

顺便提一句，我经常在Python中使用ncurses来获得这个错误。

问题

POSIX标准所规定的这种行为背后是否有任何理由？人们可以理解，它可能不可能恢复(取决于内核设计)，然而，不在内核级别自动重新启动它的理由是什么？这是因为遗产还是技术原因？如果是因为技术原因，现在这些理由是否仍然成立呢？如果这是因为遗产的原因，那么历史是什么？

Answer 1

理查德·加布里埃尔( Richard )写了一篇论文，“更坏更好”的崛起在这里讨论了Unix中的设计选择：

两位著名人士，一位来自麻省理工学院，另一位来自伯克利(但正在研究Unix)，曾见面讨论操作系统问题。这位来自麻省理工学院的人对ITS (麻省理工学院人工智能实验室操作系统)很了解，并且一直在阅读Unix源代码。他对Unix是如何解决个人电脑失败者问题感兴趣的。当用户程序调用系统例程以执行可能具有重要状态(如IO缓冲区)的长时间操作时，就会出现PC失败问题。如果在操作期间发生中断，则必须保存用户程序的状态。由于系统例程的调用通常是一条指令，用户程序的PC程序不能充分捕获进程的状态。系统例程必须要么退出，要么按前推。正确的做法是退出并将用户程序PC恢复到调用系统例程的指令，以便在中断后恢复用户程序，例如，重新进入系统例程。它之所以被称为PC loser-ing，是因为PC正被强迫进入loser mode，而在麻省理工学院，“输家”是“用户”的深情名称。这位麻省理工学院的家伙没有看到任何处理这个案件的代码，他问新泽西的那个家伙这个问题是如何处理的。新泽西人说Unix的人知道这个问题，但解决方案是系统例程总是完成，但有时会返回一个错误代码，表明系统例程没有完成它的操作。一个正确的用户程序，那么，必须检查错误代码，以确定是否简单地尝试系统例程。麻省理工学院的人不喜欢这个解决方案，因为这不是正确的事情。新泽西人说Unix解决方案是正确的，因为Unix的设计理念是简单的，正确的东西太复杂了。此外，程序员可以很容易地插入这个额外的测试和循环。麻省理工学院的人指出，实现是简单的，但接口的功能是复杂的。新泽西人说，在Unix中选择了正确的折衷方法--即实现简单性比接口简单性更重要。