针对捕获EINTR重试的系统调用包装器，合理重试次数是多少？

首先明确：write(2)、read(2)这类系统调用返回EINTR本质是可恢复的暂时性错误，封装重试是常规操作，但无限重试的风险确实存在——比如持续收到信号、或自定义系统调用实现恶意返回EINTR。工程里的合理策略需按场景划分：

核心场景与对应策略 #

• 无强约束的通用库场景：优先采用无限重试+信号防护，而非固定次数。
  关键是先规避无限循环的诱因：要么通过sigaction给信号设置SA_RESTART标志（让内核自动重启被中断的系统调用，无需自行编写重试逻辑）；要么在重试代码块内临时屏蔽会触发EINTR的信号（如SIGWINCH）。若真遇到极端的持续信号攻击，这属于系统级问题，库代码无需硬扛，交给上层或系统管理员处理更合理。
• 有超时/资源限制的场景：用固定次数阈值+超时兜底。
  比如重试5-10次，或累计重试耗时不超过1秒——这是工程经验值，既覆盖普通信号中断场景，又避免无限占用资源。超过阈值后直接返回错误，将处理权交给上层调用者（如让业务代码决定是否继续重试、或降级处理）。
• 特殊系统调用（如close(2)）：不重试。
  因为close(2)返回EINTR时，内核可能已完成部分关闭操作，重试会导致未定义行为，直接返回错误即可。

额外原则 #

库代码的重试策略要留配置入口，比如允许调用者传入重试次数、超时时间，甚至关闭重试逻辑——不要把策略写死，给上层留灵活调整的空间。

内容的提问来源于stack exchange，提问作者Madagascar