为何用sigwait处理SIGPIPE实现管道进程优雅关闭时触发信号处理器且WSL1下sigwait不生效

1. 信号掩码设置顺序错误 #

原代码先创建工作子线程，再调用pthread_sigmask配置信号阻塞，这会直接导致sigwait无法正常捕获信号：

• pthread_sigmask仅会修改调用线程（主线程）的信号掩码，子线程创建时继承的是主线程修改掩码前的状态，也就是没有阻塞SIGINT、SIGPIPE、SIGTERM。
• 信号产生时，内核会优先将信号分发到未阻塞该信号的线程，也就是你的工作子线程。此时子线程会触发预先注册的全局信号处理器，信号不会进入进程挂起队列，主线程的sigwait自然无法捕获到信号。

2. 测试场景的信号来源 #

执行./a.out | less后按q退出less时，less会关闭管道读端，你的程序继续向管道写入stdout输出时，内核会向进程发送SIGPIPE，这个信号会被内核优先分发到未阻塞它的工作子线程，触发演示用的信号处理器。 #

必须在创建任何子线程之前，先完成信号阻塞配置，确保所有线程的信号掩码都包含待等待信号的阻塞规则。只有当所有线程都阻塞对应信号时，信号才会被加入进程挂起队列，供sigwait捕获。
修正后的关键代码顺序如下：

int main()
{
    // 第一步：先配置并阻塞待等待信号
    sigset_t waitSet;
    sigemptyset(&waitSet);
    sigaddset(&waitSet, SIGINT);
    sigaddset(&waitSet, SIGPIPE);
    sigaddset(&waitSet, SIGTERM);
    // 先在主线程完成信号屏蔽
    if (pthread_sigmask(SIG_BLOCK, &waitSet, nullptr) != 0) {
        perror("pthread_sigmask failed");
        exit(EXIT_FAILURE);
    }

    // 第二步：再注册信号处理器（保留用于测试逻辑，不影响sigwait行为）
    for (int i = 1; i < 32; ++i)
    {
        // SIGKILL(9)/SIGSTOP(19)无法被捕获，调用会自动失败，无需额外处理
        std::signal(i, signalHandler);
    }

    bool run {true};
    // 第三步：此时创建子线程，子线程会继承已经设置好的阻塞掩码
    std::thread thread {[&]
        {
            while (run)
            {
                std::cout << "ping" << std::endl;
                std::this_thread::sleep_for(std::chrono::milliseconds {500});        
            }
        }};

    // 后续sigwait逻辑保持不变
    int waitSig {0};
    sigwait(&waitSet, &waitSig);
    run = false;
    thread.join();

    std::cerr << "waitSig: "  << waitSig << std::endl;
}

• 只要所有线程都阻塞了待等待信号，即使注册了对应的信号处理器，sigwait从挂起队列取走信号时也不会触发处理器，这是POSIX标准明确规定的行为。
• SIGKILL(9)和SIGSTOP(19)本身无法被捕获、阻塞或忽略，循环注册时这两个信号的signal调用会自动返回失败，不影响其余配置。

WSL1通过Windows内核仿真实现Linux系统调用，其信号子系统的模拟实现和原生Linux内核（WSL2/CentOS使用的真实内核）存在实现差异：

• 部分版本的WSL1对「阻塞信号的挂起队列维护」、「sigwait与阻塞信号的交互逻辑」的实现存在兼容缺陷，会导致阻塞的信号无法被正确加入挂起队列，无法被sigwait捕获。
• 该问题属于WSL1本身的实现限制，不属于代码逻辑问题，如需测试优先使用WSL2或原生CentOS环境。

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