【qt信号槽-6】槽函数不执行的一种原因——未知线程

背景：

项目需要调用第三方库，又要涉及多线程，遇到了在connect成功之后，槽函数依然不执行的情况。按照常理，槽函数不执行无非就几种情况：

要么connect未成功。

要么disconnect，或者对象被销毁后自动断开连接。

要么名称冲突，被扰乱秩序，包括但不限于函数名，对象名。之前写过一篇有关“提升界面”命名导致槽函数不执行的记录。本质还是connect混乱导致。

其实再有其它原因，根本还是与qt元对象实现信号槽的细节有关，万变不离其宗。

之前刚这样自信满满叨叨过，这次就遇到了奇葩，特此分享。

先说结论，诡异的子线程，有可能导致槽函数失灵。

【qt信号槽-1】槽函数重写问题，qt_metacall和qt_static_metacall_qt metacall

【qt信号槽-2】Qt中窗体继承，槽响应多次执行的解决_qt界面继承 槽函数多次执行

【qt信号槽-3】（QObject::connect: No such slot）的一种解决方法，connect函数qt4/qt5格式，元数据注册

【qt信号槽-4】槽函数不响应不执行的一种原因：ui提升导致重名_qt 按钮不能进入函数

【qt信号槽-5】信号槽相关注意事项记录

【qt信号槽-6】槽函数不执行的一种原因——未知线程

未知子线程：

先介绍一下我用到的这个第三方库，就是个dll，它用于驱动采集卡。其中有个接口，需要传入函数指针，使用回调的方式实现“插拔响应”。换句话说，当设备插拔时，会触发传入的这个函数。类似于槽函数。为后面叙述方便，先叫它“插拔函数”。

当设备插拔时，我希望更新界面状态。起初直接从这个插拔函数直接调用更新界面的函数，能用，但是qt会报错。提示不能跨线程更新界面。关于这点，插入话题。其实vs的c#里也是这样的，只不过qt提倡使用信号槽，c#是有个异步回调。终归应该都是为了线程安全这个规矩。

所以，这个诡异的子线程一定是存在的。

槽函数问题：

为了实现程序支持多个设备，我想在插拔时进行处理。插入设备就new一个管理对象，拔出设备就delete它。

结果就出问题了。这个new的对象，发出的信号可以被处理，而接受信号的槽全歇菜了。已经反复确认没有传统的那些问题，明明connect已经成功返回true，delete或deleteLater没有意外执行，甚至对象树也没有连带响应，...。还能咋地？

最终为了尝试对象树的连带关系，new时指定了parent确保万无一失。结果就报错了。一下子豁然开朗。记得在写多线程时，moveToThread之前要setParent(nullptr)，终归还是跟线程实现原理有关，比如消息队列，ownership。所以一旦代码运行到线程里，就涉及这些。最终尝试把new这段代码拿出来放在自己能控制的线程里（比如ui线程，或者自己new的线程），槽函数正常了。

反思：

为什么发出信号没问题，只有槽函数出问题呢？因为发信号是通知别人，而槽函数是基于事件循环的响应，本质上是对消息队列的处理。而所谓线程，最重要的就是消息队列的附加。这点看qt源码可以得到证实。

因此，万一那个三方库里有关线程的部分，哪里影响了消息队列。就会导致槽函数不执行。比如，那个三方库里的线程，可能就运行那一下，进而销毁了，那么相关消息队列也就失效了，所以在这个线程里new的对象，它的那些槽函数，是基于当前线程消息队列的，线程的消息队列一旦崩塌，槽函数也就失效了。

其实这个问题我并没有深究，因为不知道那个三方库里的线程到底怎么回事。就说它调用的os接口，那么原理上也是消息队列和ownership，当然ownership这点手册里没有看到说明，但可以随便写一段代码证实。我验证的结果是，moveToThread只是追加到消息队列，并不会take the ownership。亦即，适当的时候要delete。

总结：

综上所述，我觉得我基本上猜透了问题的原因，不对之处，各位多指正。

本文完。