由Qt::BlockingQueuedConnection引起的关闭Qt主页面而后台仍有进程残留-Toy模板网

这篇具有很好参考价值的文章主要介绍了由Qt::BlockingQueuedConnection引起的关闭Qt主页面而后台仍有进程残留。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

BUG：由Qt::BlockingQueuedConnection引起的关闭Qt主页面而后台仍有进程残留

1、错误代码示例

首先我们看下下面的代码，可以思考一下代码的错误之处

/** BlockingQueueDeadLock.h **/
#pragma once

#include <QtWidgets/QMainWindow>
#include "ui_BlockingQueueDeadLock.h"
#include <thread>

class BlockingQueueDeadLock : public QMainWindow
{
    Q_OBJECT

public:
    BlockingQueueDeadLock(QWidget *parent = nullptr);
    ~BlockingQueueDeadLock();

public slots:
	void RecvBlockingQueueSignal();
signals:
	void SendBlockingQueueSignal();

private:
	void startLoopTest();
	void stopLoopTest();
	void RunInThread();

private:
    Ui::BlockingQueueDeadLockClass ui;
	std::thread loopTest;
	bool m_StopFlag;
};

/** BlockingQueueDeadLock.cpp **/
#include "BlockingQueueDeadLock.h"
#include <qdebug.h>

BlockingQueueDeadLock::BlockingQueueDeadLock(QWidget *parent)
    : QMainWindow(parent)
	, m_StopFlag(false)
{
    ui.setupUi(this);
	startLoopTest();
	connect(this, &BlockingQueueDeadLock::SendBlockingQueueSignal,
		this, &BlockingQueueDeadLock::RecvBlockingQueueSignal, Qt::BlockingQueuedConnection);
}

BlockingQueueDeadLock::~BlockingQueueDeadLock()
{
	stopLoopTest();
}

void BlockingQueueDeadLock::RunInThread()
{
	qDebug("%1", std::this_thread::get_id());
	while (!m_StopFlag) {
		std::this_thread::sleep_for(std::chrono::microseconds(10));
		qDebug("signal thread: %1", std::this_thread::get_id());
		emit SendBlockingQueueSignal();
	}
}

void BlockingQueueDeadLock::RecvBlockingQueueSignal()
{
	qDebug("slot thread: %1", std::this_thread::get_id());
}

void BlockingQueueDeadLock::startLoopTest()
{
	m_StopFlag = false;
	loopTest = std::thread(&BlockingQueueDeadLock::RunInThread, this);
}

void BlockingQueueDeadLock::stopLoopTest()
{
	m_StopFlag = true;
	if (loopTest.joinable()) {
		loopTest.join();
	}
}

上面短短几十行代码竟会导致当我关闭Qt主页面时，后台的进程并没有完全退出。
blockingqueuedconnection,QT/QML,日常问题,qt,开发语言

2、原因分析

先使用转储工具获取当前后台进程的堆栈信息；右击后台进程->创建转储文件
blockingqueuedconnection,QT/QML,日常问题,qt,开发语言

这时会获得一个DMP文件，通过windbg分析该DMP文件，如下图所示
blockingqueuedconnection,QT/QML,日常问题,qt,开发语言

我们可以清晰的看到后台进程一直在等待join函数的退出；阅读源码分析join最终调用的时_Thrd_join这个接口，该接口是阻塞的，需要等待线程的主函数运行结束后才会返回。

也就是说我们RunInThread线程主函数迟迟没有结束。

BlockingQueueDeadLock::~BlockingQueueDeadLock()
{
	stopLoopTest();
}

void BlockingQueueDeadLock::RunInThread()
{
	qDebug("%1", std::this_thread::get_id());
	while (!m_StopFlag) {
		std::this_thread::sleep_for(std::chrono::microseconds(10));
		qDebug("signal thread: %1", std::this_thread::get_id());
		emit SendBlockingQueueSignal();
	}
}
void BlockingQueueDeadLock::stopLoopTest()
{
	m_StopFlag = true;
	if (loopTest.joinable()) {
		loopTest.join();
	}
}

线程的主函数就是一个while循环，在我们BlockingQueueDeadLock析构的时候会将标识符m_StopFlag置为true；按道理讲该while循环应该很快的结束并返回。

但是！但是！但是！我们是否忽略了emit这个信号发射的是如何connect的呢？

connect(this, &BlockingQueueDeadLock::SendBlockingQueueSignal,
		this, &BlockingQueueDeadLock::RecvBlockingQueueSignal， Qt::BlockingQueuedConnection);

非常非常奇怪的是为什么connect最后一个参数是Qt::BlockingQueuedConnection呢？我看到这个代码也会很奇怪，可能之前的开发者认为发送信号和接受信号的slot不在同一个线程吧！！

3、解决方案

奇怪的地方必有妖，没错就是Qt::BlockingQueuedConnection这里有问题。

先看Qt官方文档的解释：
blockingqueuedconnection,QT/QML,日常问题,qt,开发语言