pthread_sigmask误用会间接引发死锁：它不直接导致死锁，但因屏蔽信号使阻塞操作无法响应超时或中断，导致锁长期持有，最终表现为永久阻塞。
直接说结论：pthread_sigmask 在多线程中误用（尤其是主线程设置后未同步到新线程，或在加锁期间调用）会间接引发死锁，但不是死锁的直接原因——它破坏的是线程对信号的响应能力，进而让本该被信号中断的阻塞操作（如 pthread_cond_wait、sem_wait 或带超时的锁等待）无法及时退出，最终表现为“疑似死锁”的永久阻塞。
pthread_sigmask 不影响新线程的信号掩码
调用 pthread_sigmask 只作用于**当前线程**，不会继承给后续创建的 std::thread 或 pthread_create 线程。这意味着：
- 主线程调用
pthread_sigmask(SIG_BLOCK, &set, nullptr)屏蔽了SIGUSR1，不影响任何子线程——子线程默认拥有全开放的信号掩码 - 若你期望所有工作线程都屏蔽某个信号（比如避免
SIGINT中断临界区），必须在每个线程函数入口处显式调用pthread_sigmask - 漏掉这一步，就可能出现：主线程因信号被屏蔽而安全执行，但某工作线程在
pthread_cond_wait时收到SIGINT并触发默认终止动作（terminate），导致锁未释放，其他线程卡在lock_guard上
在持有 mutex 期间调用 pthread_sigmask 是危险的
虽然 pthread_sigmask 本身是异步信号安全（async-signal-safe）函数，但它若出现在锁保护的临界区内，可能造成逻辑级死锁：
- 线程 A 持有
mtx1，进入临界区后调用pthread_sigmask修改自身信号掩码 - 此时线程 B 尝试获取
mtx1被阻塞；若它正依赖某个信号（如SIGALRM）来触发超时清理，而该信号恰被线程 A 临时屏蔽，B 就无法响应定时器事件 - 更隐蔽的是：若线程 B 在等
mtx1时被投递了SIGUSR2，而它的信号处理函数里又尝试获取mtx1（未检查是否已持有），就会直接触发同一线程内重入锁 ——std::mutex不可重入，行为未定义，常见表现就是静默挂起
signal handler 中调用非 async-signal-safe 函数导致锁状态不一致
这是最易被忽略的间接死锁诱因。例如：
- 你注册了
signal(SIGUSR1, handle_sig)，并在handle_sig中调用了std::cout 或 <code>malloc - 该 handler 在线程 A 持有
std::mutex mtx的瞬间被触发；std::cout内部可能尝试获取全局 iostream mutex，而该锁与你的mtx形成嵌套依赖 - 即使没形成环，
malloc在 glibc 中会使用自己的内部锁，若此时恰好与你的业务锁发生交叉持有，且另一线程也在等这两把锁，就满足了死锁四条件中的“循环等待” - 正确做法：handler 中只做标记（如原子写
std::atomic_flag），把实际处理推迟到主逻辑中检查该标志
真正棘手的点在于：这类问题不会报错，也不触发 ASan/TSan，gdb 中看到的只是某个线程停在 futex_wait 或 __lll_lock_wait，而你翻遍锁顺序也找不到循环——因为根子在信号与锁的时空耦合上，不是代码逻辑层面的顺序错误。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
