Linux环境下Lua处理SIGINT时pcall的行为不一致问题

问题场景 #

在Lua 5.3和5.4版本中，使用print(pcall(...))形式的单行代码测试SIGINT（Ctrl+C）中断，出现三种不同行为：

• 调用os.execute("sleep 5")时：pcall返回true，但os.execute实际因SIGINT失败
• 调用io.read时：pcall捕获到错误并返回错误信息
• 调用io.lines()迭代时：直接抛出中断报错，pcall被忽略；但在外层再套一层pcall时行为恢复正常

行为的官方说明与原因 #

1. os.execute的特殊表现 #

os.execute本质是调用系统shell执行外部命令，SIGINT会直接发送给子进程（比如示例中的sleep），而非Lua虚拟机。Lua只会判定os.execute自身的调用流程完成，因此pcall返回true。你可以通过os.execute的返回值判断子进程状态：在POSIX系统中，子进程被信号终止时，返回值为128 + 信号编号（SIGINT对应130）。

2. io.read的错误捕获 #

io.read是Lua标准库的原生I/O操作，当SIGINT触发时，Lua虚拟机会将信号转化为标准Lua错误，因此能被pcall正常捕获并返回错误信息。

3. io.lines()迭代的特殊情况 #

Lua官方文档的信号处理相关章节间接说明了此现象：io.lines()返回的迭代器，底层是通过多次调用元方法__call实现的。单次pcall仅会包裹迭代器的初始化调用（即获取迭代器对象的过程），后续每次迭代获取元素的调用，都不在该pcall的捕获范围内。因此迭代过程中触发SIGINT时，错误会直接抛出，无法被单次pcall捕获。

当在外层再套一层pcall时，相当于把整个迭代循环（包括所有迭代步骤）都包裹在了错误捕获范围内，因此能正常捕获SIGINT错误。

处理SIGINT的注意事项 #

• 区分Lua层与系统层信号：对于os.execute这类调用外部进程的操作，信号会直接发送给子进程，Lua虚拟机不会感知子进程的中断状态，需通过返回值自行判断。
• 迭代器的错误捕获范围：使用io.lines()或自定义迭代器时，单次pcall仅覆盖迭代器初始化步骤。若要捕获迭代过程中的错误，需将整个循环逻辑包裹在pcall中，或在迭代器内部实现错误处理。
• 自定义信号处理的限制：可以通过debug.sethook或第三方信号库自定义SIGINT处理逻辑，但需注意：Lua的信号处理是在虚拟机钩子点触发的，处理函数中不能执行复杂操作（如I/O），否则可能引发死锁或程序不稳定。
• 版本兼容性：Lua 5.3到5.4的信号处理逻辑无重大变更，上述现象在两个版本中表现一致。

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