在 Linux 中，等待 IO 的进程可以处于 TASK_INTERRUPTIBLE 或 TASK_UNINTERRUPTIBLE 状态。
例如，后者是进程等待直到从常规文件读取完成为止的情况。如果此读取花费很长时间或永远(无论出于何种原因)，则会导致进程在此期间无法接收任何信号的问题。
前一种情况是，例如，等待从套接字读取数据(这可能需要无限长的时间)。然而，如果这样的read调用被中断，就会导致一个问题，即它要求程序员/用户正确处理errno == EINTER条件，而他可能会忘记这一点。
我的问题是:是否可以允许所有系统调用都被信号中断，并且在信号处理程序运行后，原始系统调用只是继续其业务？这不就解决了这两个问题了吗？如果不可能，为什么？
最佳答案
问题的两半是相关的，但我可能已经消化了太多的加了蛋酒的东西，以确定这里是否存在如此多的一对一关系，而不是一对多关系。
在内核方面，我认为几年前添加了 TASK_KILLABLE 状态。这样做的结果是，当进程在系统调用中阻塞时(无论出于何种原因)，如果内核遇到一个无论如何都会杀死该进程的信号，它就会顺其自然。这减少了进程永久陷入不可中断状态的可能性。我不知道在更改各个系统调用以利用该选项方面取得了哪些进展。
在用户方面，SA_RESTART 及其便利函数 siginterrupt 在一定程度上减轻了应用程序员的痛苦。但事实是，这些是按信号指定的，并且并非所有系统调用都遵守，这是一个很好的暗示，表明您提出的全面中断方案无法实现或至少无法轻松实现是有原因的。仅仅考虑信号矩阵、单个系统调用、历史上预期和向后支持的行为的调用(以及可能基于其系统血统的多个历史语义!)之间可能的交互，就有点令人眼花缭乱。但也许这就是蛋酒。
关于linux - 为什么信号处理程序在系统调用期间无法运行？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/20762821/