python信号处理器并非在底层c信号处理函数中直接执行，而是通过标志位由解释器在安全时机（如字节码指令间隙）调度执行；因此同一信号的多次触发会导致处理器被重入调用，而非排队或丢弃。
python信号处理器并非在底层c信号处理函数中直接执行，而是通过标志位由解释器在安全时机（如字节码指令间隙）调度执行；因此同一信号的多次触发会导致处理器被重入调用，而非排队或丢弃。
在CPython中，信号处理遵循“延迟执行”原则：当操作系统向进程发送信号（如 SIGUSR1）时，底层C信号处理函数仅设置一个内部标志位（pending signal flag），并不立即执行Python层的回调函数。真正的Python信号处理器（如 handle_sigusr1）由解释器在下一个安全点（通常是字节码指令执行完毕后）主动检查并调用。这一设计避免了在不可重入的C运行时环境中执行任意Python代码，从而保障解释器状态的一致性。
正因为该机制，信号处理器本质上是可重入的（reentrant） —— 当第一个处理器仍在执行（例如在 time.sleep(1) 期间），第二个相同信号到达时，C层仅再次置位标志；待当前处理器执行到下一个检查点（如循环中的下一次迭代开始前），解释器会再次进入同一处理器函数，形成逻辑上的“嵌套调用”。这正是示例中输出出现交错（如 I am taking my sweet time 1 3 出现在 2 3 之后）的根本原因：第二个信号触发的处理器抢占了执行流，执行完后控制权才交还给第一个处理器的剩余部分。
以下简化示例清晰展示了该行为：
import signal
import time
counter = 0
def handler(sig, frame):
global counter
counter += 1
print(f"[{counter}] Handler start")
for i in range(3):
print(f" [{counter}] step {i}")
time.sleep(0.5) # 模拟耗时操作
print(f"[{counter}] Handler end")
signal.signal(signal.SIGUSR1, handler)
print("Waiting for signals (send 'kill -USR1', then again during sleep)...")
time.sleep(60)⚠️ 关键注意事项：
立即学习“Python免费学习笔记（深入）”；
- 非线程安全：信号处理器运行在主线程上下文中，所有全局状态（如 global_thing 或 counter）必须手动同步；若涉及复杂对象操作，建议使用 threading.Lock 或原子操作。
- 不可预测的重入点：重入发生在字节码边界，无法精确控制哪一行之后被中断，因此避免在信号处理器中执行阻塞I/O、锁等待或修改共享数据结构。
- Linux底层限制：POSIX规定标准信号（如 SIGUSR1）不排队——若信号在已挂起状态下再次送达，仅保留一个待处理实例（即“信号合并”）。这意味着高频连续发送可能丢失部分触发；如需可靠计数，应改用 signalfd（Linux特有）或 socketpair + select 等事件驱动替代方案。
- 不可用于多线程程序：signal 模块仅对主线程有效；子线程无法安全设置或接收信号。
总结而言，Python信号机制提供的是异步通知+同步执行模型：它保证信号不会被完全忽略（除非被屏蔽），但不保证顺序、不支持排队、且执行时机受解释器调度约束。在生产环境尤其是高可靠性场景中，应优先考虑基于事件循环（如 asyncio）或进程间通信（如 multiprocessing.Queue）的替代方案，仅将信号用于轻量级生命周期控制（如优雅退出）。
