linux - QApplication 之后的清理

Question

我正在将 Qt 桌面应用程序移植到 Linux(Ubuntu 19.10、64 位桌面、Qt 5.12.5、gcc 版本 9.2.1)，并且在 QApplication 完成后发现一些意外的线程仍然处于事件状态。

这是最低重现:

#include <QApplication>
#include <unistd.h>
int main(int argc, char * argv[]) {
    {
        QApplication app(argc, argv);
        sleep(1);
    }
    sleep(10);
    return 0;
}

如果我在不同的时间点调试应用程序，我会看到以下内容:

• 在 QApplication 的构造函数运行之前，正如预期的那样，只有一个线程(主线程)存在。
• 运行 QApplication 的构造函数后，会创建 4 个附加线程:
  • QXcbEventQueue
  • 主干
  • gdbus
  • QDBusConnection
• 运行 QApplication 的析构函数后，QXcbEventQueue 线程消失。
• 即使在第二次 10 秒的 sleep 完成后，除了主线程之外的其他 3 个线程仍然保持事件状态:
  • 主干
  • gdbus
  • QDBusConnection

我正在寻找一种方法来在 QApplication 完成后正确结束这些线程(并进行其他我目前可能不知道的清理)(当然，在真实的应用程序中我调用 app.exec( )并做其他事情)并已被销毁。

这不是应用程序本身的问题，在这 3 个线程仍然处于事件状态的情况下到达 main 末尾似乎没有问题。

该应用程序是使用 Google Test 进行彻底测试的更大的库/其他应用程序套件的一部分，并且这些测试包括一些死亡测试，如果在运行一些涉及运行 QApplication 的测试后执行这些测试，则会提示 fork 一个具有多个线程的应用程序，可能会因为这个原因而卡住并且永远无法完成。

关于如何摆脱这些线程并在 QApplication 之后执行完整清理的任何提示？

Answer 1

I'm looking for a way to properly end these threads

简短回答。

你不能

长答案。

那些在 QApplication 销毁后仍然保持事件状态的线程肯定是由QApplication 创建的，但这些线程是使用分离模式on 创建的。 See了解更多信息。当任何使用分离模式on创建的线程时，它既不能加入也不能设置回可加入状态。

要验证上述检查 this代码。这是创建所有集成插件的地方。在此处添加断点并在调试期间(在 GDB 中)单步执行代码。或者您也可以为函数pthread_attr_setdetachstate设置断点。

现在来解决问题了。

检查this 。

The reason for the two death test styles has to do with thread safety. Due to well-known problems with forking in the presence of threads, death tests should be run in a single-threaded context.

因此 google-test 库开发人员非常了解您面临的问题，并且他们也针对这种情况提供了解决方案。看here

我相信这会对你有所帮助。