请评论下面这句话：
在没有rt补丁的标准Linux内核上，中断无法中断正在进行的系统调用。当从硬盘获取数据时，我们的机器不会停止工作的原因是我们用于该操作的系统调用是阻塞的。阻塞意味着一旦它向硬盘发出请求，它就会将进程状态更改为阻塞，并自愿放弃处理器时间。无法中断非实时内核上正在进行的系统调用。
这是我对这个话题的理解，但我不确定它是否正确。
答案1
系统调用可以通过使用中断信号，例如SIGINT（由CTRL+生成C）、SIGHUP等。您只能通过 PID 与系统调用交互来中断它们，但是当使用 Unix 信号和命令时kill。
rt_patch 和系统调用
@Alan 提出了以下后续问题：
中断系统调用的可能性是否与主线 Linux 内核中 rt_patch 的接受直接相关？
我的回复：
我也这么认为。在研究这个问题时，我找不到确凿的证据表明你可以/不能做到这一点，这让我相信你可以。
让我这么认为的另一个数据点是，潜在的信号Unix 内置的机制对于能够与进程交互是必要的。我不明白安装了这些补丁的系统如何能够在无法使用的情况下运行信号。
顺便说一句，信号在过程级别运行。据我所知，没有任何方法/API 可以直接向系统调用注入中断。
参考
答案2
当然，中断可以中断系统调用，除非采用适当的自旋锁，或者以其他方式禁用中断：
spin_lock_irq*()获取自旋锁并禁用硬件中断（以及软件中断和任务处理）。spin_lock_bh()获取自旋锁并禁用软件中断和微线程处理。irq_disable()禁用硬件中断。local_bh_disable()禁用软件中断和微线程处理。preempt_disable()禁用抢占，上面的任何一个也会禁用抢占。
现在，在非抢占式内核中，任务无法抢占内核模式下的其他任务。因此，如果任务 A 在您唯一的 CPU 上执行一些繁重的系统调用，而任务 B 需要将一些数据写入音频设备，则任务 B 可能需要等待任务 A 结束其系统调用，从而导致音频丢失一声咔嗒声。抢占式内核适用于这种情况。