Linux平台下强制终止阻塞的C++ std::thread的正确方法

我有一个监听Linux内核netlink事件的std::thread，它包含无限while循环和一个阻塞至下一个事件到来的函数。我希望在程序流程中不再需要该线程时强制终止它。

以下是我当前的解决方案：

#include <pthread.h>
#include <signal.h>
#include <unistd.h>
#include <iostream>
#include <thread>
#include <signal.h>

void thread_func() {
    while(true) {
        std::cout << "Processing events.." << std::endl;
        std::this_thread::sleep_for(std::chrono::seconds(10)); // 模拟阻塞等待事件的函数
        std::cout << "Events received.." << std::endl;
    }
}

int main() {
    std::thread eventListener(thread_func);
    std::this_thread::sleep_for(std::chrono::seconds(3)); // 主线程执行一些工作
    pthread_cancel(eventListener.native_handle()); // 不再需要eventListener线程
    eventListener.join();
    std::cout << "eventListener killed" << std::endl;
    return 0;
}

我的程序仅编译到Linux平台，实际使用的阻塞函数是libnl中的nl_recvmsgs_default(nl_sock* sock)。

更新：设置标志位对我无效，因为我不知道函数会阻塞多久，如果没有收到内核的新事件，函数永远不会恢复，这种情况下我只能等待标志位设为true后（直到下一次while循环处理新的netlink事件）。

问题： #

1. 这是C++中的正确实现方式吗？是否遗漏了细节？
2. 有没有更好的实现方式？
3. 如果改用pthread_kill替代pthread_cancel终止线程，为何看不到"eventListener killed"的输出？

回答 #

1. 当前实现是否正确？有没有遗漏细节？ #

用pthread_cancel配合std::thread的native_handle()在Linux上能运行，但不是C++标准推荐的做法，属于依赖POSIX扩展的平台特定实现，且存在不少隐患：

• pthread_cancel的生效依赖线程中的取消点：默认像sleep、read这类系统调用是取消点，但你实际用的nl_recvmsgs_default需要确认是否支持响应取消请求——如果libnl内部没设置取消点，线程可能无法立刻终止，甚至永远不终止。
• 线程被取消时，不会自动执行局部对象的析构函数，也不会清理线程内持有的资源（比如打开的文件句柄、动态分配的内存），极易造成资源泄漏。
• 你的代码未设置线程取消类型，默认是延迟取消（PTHREAD_CANCEL_DEFERRED），线程会等到下一个取消点才终止，导致终止时机不可控。

2. 更好的实现方式 #

既然基于libnl，最优雅的方式是主动中断阻塞的netlink接收操作，而非强制杀死线程，核心思路是给netlink socket添加一个唤醒触发源：

1. 创建一个pipe（或eventfd），通过nl_socket_add_fd将其加入netlink socket的监听集合。
2. 需要终止线程时，向pipe写入一个字节，触发nl_recvmsgs_default返回。
3. 线程内部检查终止标志位，主动退出循环并完成资源清理。

示例代码如下：

#include <iostream>
#include <thread>
#include <atomic>
#include <unistd.h>
#include <netlink/netlink.h>

std::atomic<bool> stop_flag(false);
int wake_pipe[2];

void thread_func(nl_sock* sock) {
    // 将唤醒pipe加入netlink socket的监听集合
    nl_socket_add_fd(sock, wake_pipe[0]);

    while (!stop_flag) {
        std::cout << "Waiting for netlink events.." << std::endl;
        int ret = nl_recvmsgs_default(sock);
        if (ret < 0 && !stop_flag) {
            std::cerr << "Netlink receive error: " << nl_geterror(ret) << std::endl;
        }
        // 处理收到的netlink事件...
    }

    // 清理资源
    nl_socket_free(sock);
    close(wake_pipe[0]);
}

int main() {
    // 创建唤醒pipe
    pipe(wake_pipe);

    // 初始化netlink socket
    nl_sock* sock = nl_socket_alloc();
    // 绑定socket、设置监听组等操作...

    std::thread eventListener(thread_func, sock);

    // 主线程执行业务逻辑
    std::this_thread::sleep_for(std::chrono::seconds(3));

    // 触发线程优雅终止
    stop_flag = true;
    char dummy = 'x';
    write(wake_pipe[1], &dummy, 1); // 写入字节唤醒阻塞的recv

    eventListener.join();
    close(wake_pipe[1]);

    std::cout << "eventListener exited gracefully" << std::endl;
    return 0;
}

这种方式属于优雅终止，线程可自行清理资源，符合C++的RAII原则，完全可控，没有pthread_cancel的各种不确定性。

3. 用pthread_kill看不到输出的原因 #

pthread_kill是给线程发送信号，默认情况下的问题在于：

• 如果发送SIGTERM这类默认信号，信号的默认处理是终止整个进程，而非仅杀死目标线程。主线程还没执行到std::cout << "eventListener killed"就会被一起终止，自然看不到输出。
• 若要让信号只终止线程，需要在子线程中给目标信号设置自定义处理函数，让线程捕获信号后主动退出循环。但如果线程正阻塞在nl_recvmsgs_default，信号会打断系统调用，函数返回EINTR错误，此时线程可检查终止标志后退出。如果未设置信号处理，默认信号会直接杀死整个进程。

如果要尝试pthread_kill，需先在子线程注册信号处理：

std::atomic<bool> stop_flag(false);

void sig_handler(int sig) {
    stop_flag = true;
}

void thread_func(nl_sock* sock) {
    struct sigaction sa;
    sa.sa_handler = sig_handler;
    sigemptyset(&sa.sa_mask);
    sa.sa_flags = 0;
    sigaction(SIGUSR1, &sa, nullptr); // 使用自定义信号，避免默认终止进程

    while (!stop_flag) {
        int ret = nl_recvmsgs_default(sock);
        if (ret == -EINTR) { // 被信号打断，直接进入下一轮循环检查标志位
            continue;
        }
        // 处理事件...
    }
}

// 主线程发送信号
pthread_kill(eventListener.native_handle(), SIGUSR1);
eventListener.join();

但这种方式仍不如主动唤醒pipe可靠，信号处理可能带来竞态条件，且依赖系统调用被信号打断的行为。

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