如何在dbus-cxx服务端高效阻塞主线程直到DBUS连接断开？

问题背景 #

我正在使用dbus-cxx库通过DBUS实现程序间通信，目前在服务端应用中遇到问题：如何在连接保持打开时阻止主线程退出？

首次尝试用无限循环检查连接有效性，但这种方式会浪费CPU资源：

double add(double param1, double param2) { return param1 + param2; }

void TestServer::startServer() {
    std::shared_ptr<DBus::StandaloneDispatcher> dispatcher = DBus::StandaloneDispatcher::create();

    std::shared_ptr<DBus::Connection> conn = dispatcher->create_connection(DBus::BusType::SYSTEM);

    if (conn->request_name("dbuscxx.quickstart_0.server", DBUSCXX_NAME_FLAG_REPLACE_EXISTING) !=
        DBus::RequestNameResponse::PrimaryOwner)
        return;

    // 创建包含可调用方法的对象
    std::shared_ptr<DBus::Object> object =
        conn->create_object("/dbuscxx/quickstart_0", DBus::ThreadForCalling::DispatcherThread);

    // 添加可通过DBUS调用的方法
    object->create_method<double(double, double)>("dbuscxx.Quickstart", "add", sigc::ptr_fun(add));

    while (conn->is_valid()) {
    }

    SPDLOG_INFO("Connection status {0}", conn->is_valid());
}

后来尝试在循环中加入1秒sleep，但想找到更高效的方案：

while (conn->is_valid()) {
    std::this_thread::sleep_for(std::chrono::seconds(1));
}

尝试过thread::join但dbus-cxx未提供调度器/连接线程的访问权限，也没找到可用的条件变量；能通过conn->unix_fd()获取文件描述符，但不知道如何利用它判断连接关闭。

核心问题 #

1. 无需修改dbus-cxx源码的情况下，如何高效阻塞主线程直到连接断开？
2. 带1秒sleep的无限循环作为服务方案是否足够？是否会极度低效？

解决方案与分析 #

1. 高效阻塞主线程的实现方式 #

利用conn->unix_fd()获取的文件描述符，结合poll系统调用实现阻塞等待，直到连接状态变化：

#include <poll.h>
#include <errno.h>

// ... 原有服务初始化代码 ...

struct pollfd pfd;
pfd.fd = conn->unix_fd();
// 监听消息、连接断开、错误事件
pfd.events = POLLIN | POLLHUP | POLLERR;

while (conn->is_valid()) {
    int ret = poll(&pfd, 1, -1); // 无限阻塞，直到有事件触发
    if (ret == -1) {
        // 处理中断信号（比如SIGINT），继续循环
        if (errno == EINTR) continue;
        // 其他错误直接退出
        break;
    }
    // 再次检查连接有效性，确认是否需要退出
    if (!conn->is_valid()) break;
}

SPDLOG_INFO("Connection status {0}", conn->is_valid());

• POLLIN保证DBus消息能被正常处理，调度器后台线程不受影响
• POLLHUP/POLLERR会在连接断开或出错时触发，直接唤醒主线程
• 这种方式完全阻塞主线程，没有空循环的CPU浪费，是最高效的方案之一

2. 带1秒sleep的循环方案评估 #

• 是否足够？ 对于绝大多数轻量服务场景，这个方案完全可用。DBus调度器在后台独立线程运行，sleep不会阻塞请求处理，服务功能不受影响。
• 是否极度低效？ 不会。1秒sleep意味着主线程每秒仅唤醒一次，CPU占用几乎可以忽略（远低于1%）。除非你的服务对连接断开的响应延迟有严格要求（比如需要毫秒级感知），否则这个方案的性能开销完全可接受。

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