QT-多线程中，对象信号与槽连接的问题(有时信号发射槽函数不响应原因，连接的第五个参数有关)

问题：当一个类在MoveToThread后再connect信号和槽就不好使，放在MoveToThread前面连接就可以

/**********************

连接不上的问题有很多种，如信号与槽的参数不匹配，参数为自定义类型等等。今天碰到的一个问题是多线程中，信号与槽一直连接不上。防止忘记，记录一下。

        这个问题的情景是一个QObject的派生类不是在主线程里面创建的，然后这个派生类用默认的连接方式去连接信号，这时是连接不上的。

        问题的根源就在于，异步连接的时候，这个信号是由接收者所在的线程的事件处理机制来处理的，如果接收者所在的线程没有事件处理的话，这个信号就不会被处理。看看代码：

voidQCoreApplication::postEvent(QObject*receiver,QEvent*event, int priority)

{

   if (receiver == 0) {

       qWarning("QCoreApplication::postEvent: Unexpected null receiver");

       delete event;

       return;

   }

   QThreadData* volatile *pdata= &receiver->d_func()->threadData;

   QThreadData*data = *pdata;

   if (!data) {

       // postingduring destruction? just delete the event to prevent a leak

       delete event;

       return;

   }

   // lock the postevent mutex

   data->postEventList.mutex.lock();

   // if object hasmoved to another thread, follow it

   while (data != *pdata) {

       data->postEventList.mutex.unlock();

       data =*pdata;

       if (!data) {

           //posting during destruction? just delete the event to prevent a leak

           deleteevent;

           return;

       }

       data->postEventList.mutex.lock();

   }

   QMutexUnlockerlocker(&data->postEventList.mutex);

   // if this is oneof the compressible events, do compression

   if (receiver->d_func()->postedEvents

       && self&& self->compressEvent(event,receiver,&data->postEventList)){

       return;

   }

   if (event->type() ==QEvent::DeferredDelete&&data == QThreadData::current()) {

       // rememberthe current running eventloop for DeferredDelete

       // eventsposted in the receiver's thread

       static_cast<QDeferredDeleteEvent *>(event)->level =data->loopLevel;

   }

   // delete theevent on exceptions to protect against memory leaks till the event is

   // properly ownedin the postEventList

   QScopedPointer<QEvent>eventDeleter(event);

   data->postEventList.addEvent(QPostEvent(receiver,event, priority));

   eventDeleter.take();

   event->posted =true;

   ++receiver->d_func()->postedEvents;

   data->canWait =false;

   locker.unlock();

   QAbstractEventDispatcher*dispatcher =data->eventDispatcher.loadAcquire();

   if (dispatcher)

       dispatcher->wakeUp();

}

从上面可以看出，信号被包装成一个事件加到了接收者所在的线程的事件队列当中去了。

暂时想到的几种解决方法：

在接收者创建线程中，把接收者移动到主线程中：
pReceiverObj->moveToThread(QApplication::instance()->thread());
这样发送信号的时候，就会在主线程事件队列处理中来处理了。

把connect的最后一个参数改成Qt::DirectConnection，使用直连接的方式来连接信号与槽。

启动QThread自己的事件队列处理（exec()）。
/********************************

1.多线程中的信号槽机制没有反应

只要在connect函数中第五个参数，取代默认的参数写入Qt::DirectConnection，这样就和正常的在一个线程中使用connect起到一样的效果了。

/***************************************

主线程中发出一个信号，另一个线程槽函数没有响应，这个问题搞了好几个小时，才发现原来是connect时候的第5个参数写错了，在这里做下备注吧。

connect用于连接qt的信号和槽，在qt编程过程中不可或缺。它其实有第五个参数，只是一般使用默认值，在满足某些特殊需求的时候可能需要手动设置。

Qt::AutoConnection： 默认值，使用这个值则连接类型会在信号发送时决定。如果接收者和发送者在同一个线程，则自动使用Qt::DirectConnection类型。如果接收者和发送者不在一个线程，则自动使用Qt::QueuedConnection类型。
Qt::DirectConnection：槽函数会在信号发送的时候直接被调用，槽函数运行于信号发送者所在线程。效果看上去就像是直接在信号发送位置调用了槽函数。这个在多线程环境下比较危险，可能会造成奔溃。

Qt::QueuedConnection：槽函数在控制回到接收者所在线程的事件循环时被调用，槽函数运行于信号接收者所在线程。发送信号之后，槽函数不会立刻被调用，等到接收者的当前函数执行完，进入事件循环之后，槽函数才会被调用。多线程环境下一般用这个。
Qt::BlockingQueuedConnection：槽函数的调用时机与Qt::QueuedConnection一致，不过发送完信号后发送者所在线程会阻塞，直到槽函数运行完。接收者和发送者绝对不能在一个线程，否则程序会死锁。在多线程间需要同步的场合可能需要这个。
Qt::UniqueConnection：这个flag可以通过按位或（|）与以上四个结合在一起使用。当这个flag设置时，当某个信号和槽已经连接时，再进行重复的连接就会失败。也就是避免了重复连接。
/***********************

qt信号槽在哪个线程执行的问题

QThread的使用方法

起源

      昨天不小心看到Qt开发人员( Bradley T.Hughes)Blog中的一片文章 youare-doing-it-wrong 。结果看得头昏脑胀：好歹也自学了近1年的Qt，也一直很小心、很认真地阅读Qt和manual和例子等资料，却被突然告知，QThread的正确使用方法是一种自己从没见过，而且Qtmanual、example、书籍中都没有提到过的一种方法。到底怎么了... 

      莫非manual、exmaple以及资料中的介绍都是错的？？

      认真看看其他的人的评论，总算理清了一点头绪。所有事情源于QThread 的事件循环！

QThread 的两种使用方法

1.不使用事件循环。这是官方的 Manual 、example 以及相关书籍中都介绍的一种的方法。

a. 子类化QThread

b. 重载 run函数，run函数内有一个 while 或 for 的死循环

c.设置一个标记为来控制死循环的退出。

2.使用事件循环。（博客 youare-doing-it-wrong 批驳的就是这种情况下的一种用法。）

a. 子类化QThread，

b. 重载 run使其调用 QThread::exec() 

c.并为该类定义信号和槽，这样一来，由于槽函数并不会在新开的 thread运行，很多人为了解决这个问题在构造函数中调用 moveToThread(this)
而争论和不解正是这样的一条语句造成的。
Bradley T. Hughes给出说明是： QThread应该被看做是操作系统线程的接口或控制点，而不应该包含需要在新线程中运行的代码。需要运行的代码应该放到一个QObject的子类中，然后将该子类的对象moveToThread到新线程中。

另外

      在Qt4.3(包括)之前，run 是虚函数，必须子类化QThread来实现run函数。
而从Qt4.4开始，qthreads-no-longer-abstract   ，run 默认调用 QThread::exec() 。这样一来不需要子类化 QThread 了，只需要子类化一个 QObject就够了，这正是被 Bradley T. Hughes推荐的方法。

      终于看懂了，但不管怎么说，都应该是QThread 当初的设计导致的这种问题，而所有文档和例子中都没有提到该如何使用Qthread进一步加剧了对QThread的这种误用。

QThread 使用探讨

       QThread似乎是很难的一个东西，特别是信号和槽，有非常多的人(尽管使用者本人往往不知道)在用不恰当(甚至错误)的方式在使用QThread，随便用google一搜，就能搜出大量结果出来。无怪乎Qt的开发人员 Bradley T. Hughes声嘶力竭地喊you are-doing-it-wrong。

       和众多用户一样，初次看到这个时，感到 Bradley T.Hughes有 些莫名奇妙，小题大作。尽管不舒服，当时还是整理过一篇博客QThread的使用方法

      时间过去3个月，尽管依然没怎么用thread；但今天csdn论坛中有人问到这个问题，想想还是尽我所能整理一下吧。提升自己，方便他人，何乐而不为呢?

      QThread东西还是比较多的，而且我对底层对象了解有限，仅就一点进行展开(或许是大家最关心的一点)：QThread中的slots在那个线程中执行？

QThread::run

run 函数是做什么用的？Manual中说的清楚：

• run对于线程的作用相当于main函数对于应用程序。它是线程的入口，run的开始和结束意味着线程的开始和结束。

原文如下(这段话我们称为定理一吧)：

• Therun() implementation is for a thread what the main() entry point isfor the application. All code executed in a call stack that startsin the run() function is executed by the new thread, and the threadfinishes when the function returns.

这么短的文字一眼就看完了，可是，这是什么意思呢？又能说明什么问题呢？看段简单代码：

class Thread:public QThread { Q_OBJECT public: Thread(QObject* parent=0):QThread(parent){} public slots: void slot() { ... } signals: void sig(); protected: void run() { ...} }; int main(int argc, char** argv) { ... Thread thread; ... }

对照前面的定理，run函数中的代码时确定无疑要在次线程中运行的，那么其他的呢？比如 slot是在次线程还是主线程中运行？

你想说主线程，但又心有不甘，对么？

QObject::connect

      涉及信号槽，我们就躲不过 connect函数，只是这个函数大家太熟悉。我不好意思再用一堆废话来描述它，但不说又不行，那么折中一下，只看它的最后一个参数吧(为了简单起见，只看它最常用的3个值)

      下面的列表，我们暂称为定理二:

• 自动连接(Auto Connection)
  • 这是默认设置
  • 如果信号在接收者所依附的线程内发射，则等同于直接连接
  • 如果发射信号的线程和接受者所依附的线程不同，则等同于队列连接
  • 也就是这说，只存在下面两种情况
• 直接连接(Direct Connection)
  • 当信号发射时，槽函数将直接被调用。
  • 无论槽函数所属对象在哪个线程，槽函数都在发射信号的线程内执行。
• 队列连接(Queued Connection)
  • 当控制权回到接受者所依附线程的事件循环时，槽函数被调用。
  • 槽函数在接收者所依附线程执行。

      同前面一样，这些文字大家都能看懂。但含义呢？

      不妨继续拿前面的例子来看，slot函数是在主线程还是次线程中执行呢？

      定理二强调两个概念：发送信号的线程 和 接收者所依附的线程。而slot 函数属于我们在main中创建的对象 thread，即thread依附于主线程

• 队列连接告诉我们：槽函数在接受者所依附线程执行。即 slot将在主线程执行
• 直接连接告诉我们：槽函数在发送信号的线程执行。信号在那个线程发送呢？？不定！
• 自动连接告诉我们：二者不同，等同于队列连接。即 slot在主线程执行

      太绕了？不是么（要彻底理解这几句话，你可能需要看Qtmeta-object系统和Qt event系统）

怎么办呢？

      如果上两节看不懂，就记住下面的话吧（自己总结的，用词上估计会不太准确）。

• QThread是用来管理线程的，它所依附的线程和它管理的线程并不是同一个东西
• QThread 所依附的线程，就是执行 QThread t(0) 或QThread * t=new QThread(0) 的线程。也就是咱们这儿的主线程
• QThread 管理的线程，就是 run启动的线程。也就是次线程
• 因为QThread的对象依附在主线程中，所以他的slot函数会在主线程中执行，而不是次线程。除非：
  • QThread对象依附到次线程中(通过movetoThread)
  • slot和信号是直接连接，且信号在次线程中发射
• 但上两种解决方法都不好，因为QThread不是这么用的(Bradley T.Hughes)

      好了，不再添加更多文字了，看代码，估计咱们都会轻松点

主线程(信号)QThread(槽)

      这是 Qt Manual 和例子中普遍采用的方法。 但由于manual没说槽函数是在主线程执行的，所以不少人都认为它应该是在次线程执行了。

• 定义一个 Dummy 类，用来发信号
• 定义一个 Thread 类，用来接收信号
  • 重载 run 函数，目的是打印 threadid

#include /QCoreApplication> #include /QObject> #include /QThread> #include /QDebug> class Dummy:public QObject { Q_OBJECT public: Dummy(){} public slots: void emitsig() { emit sig(); } signals: void sig(); }; class Thread:public QThread { Q_OBJECT public: Thread(QObject* parent=0):QThread(parent) { //moveToThread(this); } public slots: void slot_main() { qDebug()<<"from thread slot_main:" <<currentThreadId(); } protected: void run() { qDebug()<<"thread thread:"<<currentThreadId(); exec(); } }; #include "main.moc" int main(int argc, char *argv[]) {   QCoreApplication a(argc, argv); qDebug()<<"main thread:"<<QThread::currentThreadId(); Thread thread; Dummy dummy; QObject::connect(&dummy, SIGNAL(sig()), &thread, SLOT(slot_main())); thread.start(); dummy.emitsig(); return a.exec(); }

然后看到结果(具体值每次都变，但结论不变)

main thread: 0x1a40 from thread slot_main: 0x1a40 thread thread: 0x1a48

看到了吧，槽函数的线程和主线程是一样的！

如果你看过Qt自带的例子，你会发现 QThread 中 slot 和 run函数共同操作的对象，都会用QMutex锁住。为什么？

因为slot和run处于不同线程，需要线程间的同步！

如果想让槽函数slot在次线程运行(比如它执行耗时的操作，会让主线程死掉)，怎么解决呢？

• 注意：dummy信号是在主线程发射的， 接收者 thread也在主线程中。
• 参考我们前面的结论，很容易想到:
  • 将 thread依附的线程改为次线程不就行了？
  • 这也是代码中注释掉的moveToThread(this)所做的，去掉注释，你会发现slot在次线程中运行

main thread: 0x13c0 thread thread: 0x1de0 from thread slot_main: 0x1de0

这可以工作，但这是Bradley T. Hughes 强烈批判的用法。推荐的方法后面会给出。

run中信号与QThread中槽

• 定义一个 Dummy 类，在run中发射它的信号
  • 也可以在run中发射 Thread类中的信号，而不是Dummy（效果完全一样）
• QThread 定义槽函数，重载run函数

#include /QCoreApplication> #include /QObject> #include /QThread> #include /QDebug> class Dummy:public QObject { Q_OBJECT public: Dummy(QObject* parent=0):QObject(parent){} public slots: void emitsig() { emit sig(); } signals: void sig(); }; class Thread:public QThread { Q_OBJECT public: Thread(QObject* parent=0):QThread(parent) { //moveToThread(this); } public slots: void slot_thread() { qDebug()<<"from thread slot_thread:" <<currentThreadId(); } signals: void sig(); protected: void run() { qDebug()<<"thread thread:"<<currentThreadId(); Dummy dummy; connect(&dummy, SIGNAL(sig()), this, SLOT(slot_thread())); dummy.emitsig(); exec(); } }; #include "main.moc" int main(int argc, char *argv[]) { QCoreApplication a(argc, argv); qDebug()<<"main thread:"<<QThread::currentThreadId();Thread thread; thread.start(); return a.exec(); }

想看结果么？

main thread: 0x15c0 thread thread: 0x1750 from thread slot_thread: 0x15c0

• 其实没悬念，肯定是主线程
  • thread对象本身在主线程。所以它的槽也在要在主线程执行

如何解决呢？

• （方法一）前面提了moveToThread,这儿可以用，而且可以解决问题。当同样，是被批判的对象。
• （方法二）注意哦，这儿我们的信号时次线程发出的，对比connect连接方式，会发现：
  • 采用直接连接，槽函数将在次线程(信号发出的线程)执行
  • 这个方法不太好，因为你需要处理slot和它的对象所在线程的同步。需要QMutex 一类的东西

推荐的方法

      千呼万唤始出来。

      其实，这个方法太简单，太好用了。定义一个普通的QObject派生类，然后将其对象move到QThread中。使用信号和槽时根本不用考虑多线程的存在。也不用使用QMutex来进行同步，Qt的事件循环会自己自动处理好这个。

#include /QCoreApplication> #include /QObject> #include /QThread> #include /QDebug> class Dummy:public QObject { Q_OBJECT public: Dummy(QObject* parent=0):QObject(parent) {} public slots: void emitsig() { emit sig(); } signals: void sig(); }; class Object:public QObject { Q_OBJECT public: Object(){} public slots: void slot() { qDebug()<<"from thread slot:" <<QThread::currentThreadId(); } }; #include "main.moc" int main(int argc, char *argv[]) { QCoreApplication a(argc, argv); qDebug()<<"main thread:"<<QThread::currentThreadId(); QThread thread; Object obj; Dummy dummy; obj.moveToThread(&thread); QObject::connect(&dummy, SIGNAL(sig()), &obj, SLOT(slot())); thread.start(); dummy.emitsig(); return a.exec(); }

      结果：main thread: 0x1a5c from thread slot: 0x186c

恩，slot确实不在主线程中运行（这么简单不值得欢呼么？）

下面放一个排版好的代码

#include <QtWidgets/QApplication>
#include <QObject> 
#include <QThread> 
#include <QDebug> 
class Dummy1 :public QObject {
    Q_OBJECT
public:
    //     Dummy1(QObject* parent = 0):QObject(parent)
    //     {}
    public slots :
        void emitsig()
    {
        emit sig();
    }
signals:
    void sig();
};

class Object :public QObject {
    Q_OBJECT
public:
    Object()
    {}
    public slots :
        void slot()
    {
        qDebug() << "from thread slot:" << QThread::currentThreadId();
    }
};

int main(int argc, char *argv[]) {
    
    QCoreApplication a(argc, argv);
    qDebug() << "main thread:" << QThread::currentThreadId();
    QThread thread; 
    Object obj;
    Dummy1 dummy;
    //obj.moveToThread(&thread);
    QObject::connect(&dummy, SIGNAL(sig()), &obj, SLOT(slot())); thread.start(); 
    dummy.emitsig();
    return a.exec();
}