【问题标题】:Can non-blocking system calls be interrupted?可以中断非阻塞系统调用吗?
【发布时间】:2018-06-11 17:41:55
【问题描述】:

我正在阅读The Linux Programming Interface,它描述了(在第 21.5 节中)阻塞系统调用如何被信号中断。这似乎意味着不能中断非阻塞系统调用。这是真的吗?

【问题讨论】:

  • 由于信号是异步的,SIGINT 可能会在任何系统调用之外中断您的程序。我想知道在调用非阻塞系统调用之后但在它返回之前是否可以中断程序。
  • 我认为通常任何系统调用都可以被信号中断。 “非阻塞”仅意味着进行系统调用不会取消您的进程,但系统调用仍然必须运行,并且在此期间可能会有信号到达。
  • 是的,这对我来说很有意义。也许这个例子专门提到阻塞系统调用只是因为它们更有可能被中断,但是这本书对它如何描述一切非常精确,所以我觉得它真的只针对阻塞系统调用,但我没有证据为此
  • 我想你可以通过调用 alarm() 来安排信号,然后在紧密循环中调用一些非阻塞调用并检查信号处理程序中的堆栈内容并检查返回值来测试它来自系统调用

标签: c linux linux-kernel signals system-calls


【解决方案1】:

这个问题几乎没有意义,因为在中断系统调用的信号和在系统调用之前或之后一个周期中断用户空间的信号之间几乎没有或没有(不可移植)可观察到的区别。

【讨论】:

  • 编程时不是没有意义的;如果可以中断非阻塞系统调用,则程序员必须默认检查错误代码 EINTR,在这种情况下,系统调用可能需要重新启动(正常和预期的行为)。如果无法中断非阻塞系统调用,则无需进行此检查,并且失败的系统调用可能是致命的 - 假设所有非阻塞系统调用都无法中断可能会导致不必要的致命错误
  • 哦,EINTR。如果您不打算将中断视为实际错误,则根本不要启用它。这是一个虚假的意图,因为它具有固有的竞争条件。所以根本不要启用它。
  • 我更多是从理论角度提出这个问题,以便更好地理解 Linux 内核,但是是的,这是一种可能的解决方法
  • @dippynark:关于错误处理:如果任何函数调用的失败以不希望的方式影响程序的行为,请处理记录设置的每个错误代码。
  • @alk 我知道如何处理/找出系统调用错误,我问这个问题是为了了解更多关于内核如何工作的信息——可能返回的错误并不是你唯一需要做的事情考虑一下,如果您正在使用信号处理程序并且您不知道程序何时可以被中断,那么重入可能会导致问题
猜你喜欢
  • 2012-01-20
  • 1970-01-01
  • 2020-11-11
  • 1970-01-01
  • 2014-05-27
  • 1970-01-01
  • 1970-01-01
  • 2012-04-21
  • 1970-01-01
相关资源
最近更新 更多