POSIX共享库中信号处理的惯用实现方案及问题求解

一、SIG_DFL场景的通用POSIX兼容处理 #

你当前硬编码信号默认行为的写法不具备跨POSIX平台兼容性，核心问题是错误地在用户态预判信号的默认动作，实际上内核本身就内置了所有信号的默认处理逻辑，完全不需要用户态做判断。
修正逻辑非常简单：

• 当检测到旧信号处理器为SIG_DFL时，先调用sigaction将信号处理器完整还原为你保存的旧sigaction结构（包括sa_mask、sa_flags所有字段，不要只修改handler），之后直接调用raise(signo)重新向自身发送同编号信号即可。
• 内核收到raise触发的信号后，会自动按照当前系统的POSIX标准规则执行默认动作：不管是忽略信号、终止进程、生成coredump还是暂停进程，行为完全和系统原生默认逻辑一致，不需要你硬编码任何信号的属性，全POSIX平台通用。
• 你之前的代码重置完处理器就直接return的写法存在逻辑缺陷：如果没有设置SA_RESETHAND标志，从信号处理器返回后会回到触发异常的指令重新执行，虽然最终也可能触发默认处理，但会多一次无效的异常触发，在部分平台上还可能出现信号掩码不对、递归触发的问题，直接raise是最稳妥的实现。

修正后的SIG_DFL分支代码如下：

else if (act->sa_handler == SIG_DFL)
{
  // 完整还原默认信号配置
  sigaction(signo, act, nullptr);
  // 重发信号交由内核执行默认逻辑
  raise(signo);
  return;
}

二、共享库信号处理器生命周期与链式调用冲突处理 #

你提到的独立分配可执行内存存放跳板逻辑的思路是可行的，但工程实现上有更简单、符合工业界实践的标准方案，核心是要先明确一个前提：POSIX标准没有提供任何安全机制，允许共享库在存在外部回调引用（比如信号处理器链、atexit回调、线程回调）的情况下被安全卸载，强行做卸载时的处理器还原必然会破坏链式调用或者产生悬空指针。
可选的实现方案按优先级从高到低排列：

• 最稳妥、最常用的方案：直接禁止共享库被动态卸载。在库初始化逻辑里调用dlopen加载自身句柄（比如dlopen("你的库名.so", RTLD_NOW | RTLD_LOCAL)，或者传NULL加载全局符号表），人为给库增加一个引用计数，这样就算外部调用dlclose，库的引用计数也不会降到0，代码段永远不会被操作系统回收，从根源上避免处理器函数地址变成悬空指针，也不需要在卸载时修改信号处理器链，完全不会破坏后续模块注册的处理器逻辑。绝大多数需要注册全局回调的生产级共享库（比如内存检测库、信号处理封装库）都采用这个方案。
• 如果必须支持共享库卸载，就采用极简跳板方案：用mmap分配进程生命周期的匿名内存（分配时设置PROT_READ | PROT_WRITE | PROT_EXEC权限，这段内存不会随库卸载被回收），在里面写入极短的跳板执行逻辑，跳板只保存三个状态：原子状态标记（标记库是否已卸载）、你保存的旧sigaction结构、库内实际处理函数的地址。信号触发时先进入跳板：如果检测到库已卸载，直接调用保存的旧处理器，完全不访问已卸载的库代码；如果库未卸载，再判断是否为自身触发的SIGSEGV，再决定走自身处理逻辑还是转发给旧处理器。库卸载时只需要把跳板里的原子标记设为已卸载状态，绝对不要修改全局的sigaction配置，这样后续模块注册的信号链完全不会被破坏，也不会出现悬空指针问题。
• 绝对不要在库卸载时主动把信号处理器还原为你加载时保存的旧处理器值：你保存的旧值只代表你注册处理器之前的状态，无法感知之后其他模块注册的新处理器，强行还原会直接覆盖后续模块注册的处理器，彻底破坏信号调用链。

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