C++主线程轮询阻塞实现的正确性、复杂度及信号终止问询

1. 代码是否正确？ #

整体逻辑是正确的，但存在几个细节上的潜在问题：

• 多次信号触发的冗余处理：如果连续收到多次SIGINT/SIGTERM信号，P_SEM.release()会多次释放信号量，但termination_handler中的acquire()只会执行一次，剩余的信号量释放会让信号量处于已触发状态。不过主线程退出后整个进程会终止，异步线程也会随之结束，不会导致永久阻塞，属于非致命问题。
• std::async的线程等待行为：std::async(std::launch::async)创建的线程，其对应的std::future（即t_termination_handler）在销毁时会等待线程执行完成。如果程序从未收到终止信号，主线程会一直循环，异步线程会持续阻塞在P_SEM.acquire()，这符合设计预期。
• 信号处理函数的注册：代码中未处理std::signal的返回值（原信号处理函数），虽然不影响核心功能，但健壮性不足，建议保存原处理函数并在程序退出时恢复（可选）。

核心的信号安全部分是正确的：std::binary_semaphore::release()是C++20标准明确规定的信号安全操作，可以在信号处理函数中安全调用。

2. 实现是否过于复杂？ #

是的，当前实现确实可以简化。你不需要额外启动一个异步线程来中转信号事件，直接在主线程中结合信号量和定时逻辑即可，比如：

#include <atomic>
#include <semaphore>
#include <chrono>
#include <csignal>
#include <thread>

std::binary_semaphore exit_sem{0};
std::atomic<bool> shutdown{false};

void signal_handler(int) {
    shutdown.store(true, std::memory_order_relaxed);
    exit_sem.release();
}

int main() {
    std::signal(SIGINT, signal_handler);
    std::signal(SIGTERM, signal_handler);

    using namespace std::chrono_literals;
    const auto interval = 20s;

    do {
        // 执行每20秒一次的任务
        // ...

        // 等待间隔或终止信号
        std::chrono::steady_clock::time_point start = std::chrono::steady_clock::now();
        while (true) {
            auto time_left = interval - (std::chrono::steady_clock::now() - start);
            if (time_left <= std::chrono::seconds(0)) break;

            // 尝试等待剩余时间，若信号触发则退出循环
            if (exit_sem.try_acquire_for(time_left)) {
                break;
            }
        }
    } while (!shutdown);

    return 0;
}

这个简化版本去掉了条件变量和异步线程，直接在主线程中通过try_acquire_for同时处理定时和信号触发，逻辑更简洁。

关于信号处理函数中的安全操作 #

信号处理函数处于特殊的执行上下文，只能调用信号安全的操作，C++标准和POSIX规范明确的安全操作包括：

• std::binary_semaphore/std::counting_semaphore的release()操作（C++20及以上）。
• std::atomic的所有lock-free操作（如store/load/exchange等）。
• POSIX定义的信号安全C函数（如_exit、write、kill等），注意不能调用printf、malloc、free这类非安全函数。
• 不能抛出C++异常，不能调用任何可能分配/释放内存的函数，也不能调用std::cout、std::cerr这类IO流操作。

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