信号（signal）是“异步中断”，不能直接做复杂操作，异步中断是什么意思?

（千问生成）

🎯 一句话总结：

“异步中断” = 程序正在做 A 事，突然被强行打断，去处理 B 事，而 A 完全不知道自己什么时候会被打断。

就像你正在认真写作业，突然电话响了——你不得不立刻放下笔去接电话，哪怕你正写到最关键的一行！

---

🧩 拆解关键词

1. “中断（Interrupt）”

• 来自硬件或操作系统的强制打断机制
• CPU 会立即暂停当前任务，跳转去执行一个特殊函数（中断处理程序）
• 执行完再回到被打断的地方继续

✅ 在操作系统中，信号（signal）就是一种软件中断。

---

2. “异步（Asynchronous）”

• 不按顺序发生，和主程序的执行流程没有固定时序关系
• 你无法预测它何时到来
• 它可能在任何一条指令之间发生！

💡 对比“同步”：比如你调用 printf()，你知道它什么时候开始、什么时候结束——这是可预测、有序的。

---

📞 生活比喻：电话 vs 面对面聊天

场景	类型	特点
你打电话给朋友“喂，帮我查个数据！”朋友查完告诉你结果	同步（Synchronous）	- 你主动发起- 你知道要等多久- 流程可控
你正在做饭，突然手机响了你不得不放下锅铲去接打完再回来继续炒菜	异步中断（Asynchronous Interrupt）	- 你没主动请求- 随时可能打断你- 你不知道它何时来- 必须快速处理完就回去

信号（signal）就像那个突如其来的电话！

---

💻 回到你的程序

假设你的代码正在执行这行：

int total = a + b; // 正在做加法

但就在这两个 CPU 指令之间（比如刚读取 a，还没读 b），操作系统突然说：

“嘿！用户按了 Ctrl+C！快处理 SIGINT！”

于是 CPU 立刻跳转到你的 SignalHandler 函数：

void SignalHandler(int signum) {
    exit_requested_ = true;   // ← 这里！
    write(selfpipe_[1], ...); // ← 这里！
}

⚠️ 危险来了：你不知道主程序“卡在哪”！

想象主程序正在做一件复杂的事，比如：

// 主线程正在向日志文件写入一条完整记录
log_file << "Start transaction\n";
log_file << "Update balance: " << new_balance << "\n"; // ← 刚写到这里！
log_file << "Commit success\n";

如果信号在这时触发，而你在 SignalHandler 里也尝试写日志：

void SignalHandler(int signum) {
    LOG_INFO(MSG) << "Caught signal!"; // ❌ 危险！
}

那么可能发生：

• 日志缓冲区被两个“写操作”同时修改 → 内容错乱
• 文件指针状态不一致 → 崩溃或数据损坏

因为 std::cout / LOG_INFO 这些函数内部用了锁、缓冲区、动态内存——它们不是信号安全的！

---

✅ 为什么 write() 到 pipe 是安全的？

POSIX 标准明确规定了一小部分函数是 async-signal-safe（信号安全的），包括：

• write()
• read()
• _exit()
• kill()
• 一些简单的系统调用

它们的特点：

• 不分配内存
• 不使用全局锁
• 不依赖程序当前状态

所以，在 SignalHandler 里只做一件事：

write(selfpipe_[1], "x", 1); // 安全！

然后立刻返回。真正的退出逻辑（关 ZBUS、清线程池）留给主线程在安全环境下执行。

---

🔁 总结：为什么信号是“异步中断”？

特性	说明
异步（Asynchronous）	你无法控制它何时发生——可能在任何指令之间
中断（Interrupt）	强制暂停当前执行流，跳转到信号处理函数
危险	信号处理函数不能调用大多数普通函数（非 async-signal-safe）
解决方案	只做最简单、最安全的操作（如 write 到 pipe），把复杂逻辑交给主循环

---

🌟 记住这个口诀：

信号如闪电，来去不由你；
处理要轻巧，复杂留主序。