多线程应用优雅终止：sigaction与sigwait方案对比及sigwait弊端探讨

我有一个需要实现优雅终止的多线程应用，目前采用sigaction注册信号处理函数，通过信号量通知主线程及其他线程启动关闭流程。选择信号量的原因是其具备异步信号安全性，可在信号处理函数中安全调用。

对应的实现代码如下：

#include <stdio.h>
#include <signal.h>
#include <semaphore.h>
#include <errno.h>

// 信号量是少数可在异步信号处理中安全使用的同步机制
sem_t signalSemaphore;

void signalHandler(int signal) {
  sem_post(&signalSemaphore);
}

void start_threads() {
  printf("Starting threads!\n");
}

void stop_threads() {
  printf("Stopping threads\n");
}

int main(int argc, char** argv) {
  if (sem_init(&signalSemaphore, 0, 0)) {
    perror("Unable to init semaphore");
    return 1;
  }

  struct sigaction newAction;
  newAction.sa_handler = signalHandler;
  sigemptyset(&newAction.sa_mask);
  newAction.sa_flags = 0;
  sigaction(SIGINT, &newAction, NULL);
  sigaction(SIGTERM, &newAction, NULL);

  start_threads();

  for(;;) {
    if(sem_wait(&signalSemaphore)) {
      if(errno != EINTR) {
        // EINTR由信号触发，非该值则为异常错误
        perror("Error while waiting for semaphore");
        return 1;
      }
    } else {
      break;
    }
  }

  stop_threads();

  if(sem_destroy(&signalSemaphore)) {
    perror("Error destroying semaphore");
    return 1;
  }
}

另一种更简洁的优雅终止方案是阻塞SIGINT和SIGTERM信号，使用sigwait等待信号触发。该方案无需信号量和自定义信号处理函数，我考虑它的核心原因是macOS不支持信号量，原方案可移植性较差。

对应的实现代码如下：

#include <stdio.h>
#include <signal.h>

void stop_threads() {
  printf("Stopping threads!\n");
}

void start_threads() {
  printf("Starting threads\n");
}

int main(int argc, char** argv) {
  start_threads();

  sigset_t sigset;
  sigemptyset(&sigset);
  sigaddset(&sigset, SIGINT);
  sigaddset(&sigset, SIGTERM);
  sigprocmask(SIG_BLOCK, &sigset, NULL);

  // 等待信号进入pending状态（已生成但未投递）
  int sig;
  if(sigwait(&sigset, &sig)) {
    perror("Error calling sigwait");
  }

  stop_threads();
}

我的问题是：使用sigwait替代sigaction及自定义信号处理函数是否存在任何弊端？

利弊分析：sigwait vs sigaction+信号量 #

sigwait方案的优势

• 代码更简洁：无需维护信号量的初始化、销毁逻辑，也不用编写信号处理函数，减少了代码复杂度。
• 可移植性更强：sigwait是POSIX标准接口，macOS、Linux等主流系统均支持，解决了原方案依赖信号量导致的兼容性问题。
• 避免异步信号安全限制：信号处理函数只能调用极少数异步信号安全的函数，而sigwait是在同步上下文处理信号，可直接调用任意线程安全的函数，无需额外限制。

需要注意的潜在弊端/风险

• 信号阻塞范围问题：sigprocmask设置的信号掩码是进程级的，所有线程都会继承该掩码。如果你的应用中存在其他线程需要处理SIGINT/SIGTERM（比如局部资源清理），这些信号会被全部拦截到调用sigwait的主线程，其他线程无法收到信号。而原方案中，信号处理函数仅负责触发信号量，其他线程仍可正常接收信号（除非额外设置掩码）。
• 信号丢失风险：如果在调用sigprocmask阻塞信号之前，就有SIGINT/SIGTERM信号到达，进程会执行信号的默认处理逻辑（比如直接终止），sigwait无法捕获该信号，导致无法触发优雅终止。因此必须确保在启动任何线程、可能收到信号之前就完成信号掩码的设置。原方案中先注册信号处理函数再启动线程，信号到达时会触发处理函数，不会丢失。
• 多信号触发的处理限制：对于非实时信号（如SIGINT/SIGTERM），系统不会排队存储多个相同信号。如果连续收到多次相同信号，sigwait只会返回一次；原方案中每次信号触发都会调用sem_post，信号量计数会累加，但原代码仅处理一次终止逻辑，两者实际效果差异不大，但如果需要统计信号触发次数，原方案的信号量可以直接计数，而sigwait需要额外维护计数器。
• 多线程等待信号的灵活性不足：如果有多个线程需要等待不同信号，sigwait可以通过多个线程分别监听不同信号集实现，但原方案可以通过多个信号量分别通知不同线程，灵活性上各有优劣，但sigwait的多线程监听需要注意信号掩码的同步。

总结 #

如果你的应用中没有其他线程需要处理SIGINT/SIGTERM，且能确保在任何信号到达前就完成信号掩码的设置，sigwait方案在可移植性和代码简洁性上是更优的选择。反之，如果需要其他线程响应目标信号，或者无法保证信号掩码的设置时机，原方案的兼容性更好。

内容的提问来源于stack exchange，提问作者Imanol Barba Sabariego