现在我们已经讨论过事件循环。我们说,每一个 Qt 应用程序至少有一个事件循环,就是调用了QCoreApplication::exec()
的那个事件循环。不过,QThread
也可以开启事件循环。只不过这是一个受限于线程内部的事件循环。因此我们将处于调用main()
函数的那个线程,并且由QCoreApplication::exec()
创建开启的那个事件循环成为主事件循环,或者直接叫主循环。注意,QCoreApplication::exec()
只能在调用main()
函数的线程调用。主循环所在的线程就是主线程,也被成为 GUI 线程,因为所有有关 GUI 的操作都必须在这个线程进行。QThread
的局部事件循环则可以通过在QThread::run()
中调用QThread::exec()
开启:
记得我们前面介绍过,Qt 4.4 版本以后,QThread::run()
不再是纯虚函数,它会调用QThread::exec()
函数。与QCoreApplication
一样,QThread
也有QThread::quit()
和QThread::exit()
函数来终止事件循环。
线程的事件循环用于为线程中的所有QObjects
对象分发事件;默认情况下,这些对象包括线程中创建的所有对象,或者是在别处创建完成后被移动到该线程的对象(我们会在后面详细介绍“移动”这个问题)。我们说,一个QObject
的所依附的线程(thread affinity)是指它所在的那个线程。它同样适用于在QThread
的构造函数中构建的对象:
- {
- public:
- MyThread()
- {
- otherObj = new QObject;
- }
- private:
- QObject obj;
- QObject *otherObj;
- QScopedPointer yetAnotherObj;
- };
在我们创建了MyThread
对象之后,obj
、otherObj
和yetAnotherObj
的线程依附性是怎样的?是不是就是MyThread
所表示的那个线程?要回答这个问题,我们必须看看究竟是哪个线程创建了它们:实际上,是调用了MyThread
构造函数的线程创建了它们。因此,这些对象不在MyThread
所表示的线程,而是在创建了MyThread
的那个线程中。
我们可以通过调用可以查询一个QObject
的线程依附性。注意,在QCoreApplication
对象之前创建的QObject
没有所谓线程依附性,因此也就没有对象为其派发事件。也就是说,实际是QCoreApplication
创建了代表主线程的QThread
对象。
我们可以使用线程安全的QCoreApplication::postEvent()
函数向一个对象发送事件。它将把事件加入到对象所在的线程的事件队列中,因此,如果这个线程没有运行事件循环,这个事件也不会被派发。
QObject
的线程依附性是可以改变的,方法是调用QObject::moveToThread()
函数。该函数会改变一个对象及其所有子对象的线程依附性。由于QObject
不是线程安全的,所以我们只能在该对象所在线程上调用这个函数。也就是说,我们只能在对象所在线程将这个对象移动到另外的线程,不能在另外的线程改变对象的线程依附性。还有一点是,Qt 要求QObject
的所有子对象都必须和其父对象在同一线程。这意味着:
- 不能对有父对象(parent 属性)的对象使用
QObject::moveToThread()
函数 - 不能在
QThread
中以这个QThread
本身作为父对象创建对象,例如:
- class Thread : public QThread {
- void run() {
- QObject *obj = new QObject(this); // 错误!
- }
- };
这是因为QThread
对象所依附的线程是创建它的那个线程,而不是它所代表的线程。
Qt 还要求,在代表一个线程的QThread
对象销毁之前,所有在这个线程中的对象都必须先delete
。要达到这一点并不困难:我们只需在QThread::run()
的栈上创建对象即可。
现在的问题是,既然线程创建的对象都只能在函数栈上,怎么能让这些对象与其它线程的对象通信呢?Qt 提供了一个优雅清晰的解决方案:我们在线程的事件队列中加入一个事件,然后在事件处理函数中调用我们所关心的函数。显然这需要线程有一个事件循环。这种机制依赖于 moc 提供的反射:因此,只有信号、槽和使用Q_INVOKABLE
宏标记的函数可以在另外的线程中调用。
QMetaObject::invokeMethod()
静态函数会这样调用:
主意,上面函数调用中出现的参数类型都必须提供一个公有构造函数,一个公有的析构函数和一个公有的复制构造函数,并且要使用函数向 Qt 类型系统注册。
跨线程的信号槽也是类似的。当我们将信号与槽连接起来时,QObject::connect()
的最后一个参数将指定连接类型:
Qt::DirectConnection
:直接连接意味着槽函数将在信号发出的线程直接调用Qt::QueuedConnection
:队列连接意味着向接受者所在线程发送一个事件,该线程的事件循环将获得这个事件,然后之后的某个时刻调用槽函数Qt::BlockingQueuedConnection
:阻塞的队列连接就像队列连接,但是发送者线程将会阻塞,直到接受者所在线程的事件循环获得这个事件,槽函数被调用之后,函数才会返回Qt::AutoConnection
:自动连接(默认)意味着如果接受者所在线程就是当前线程,则使用直接连接;否则将使用队列连接
注意在上面每种情况中,发送者所在线程都是无关紧要的!在自动连接情况下,Qt 需要查看信号发出的线程是不是与接受者所在线程一致,来决定连接类型。注意,Qt 检查的是信号发出的线程,而不是信号发出的对象所在的线程!我们可以看看下面的代码:
- class Thread : public QThread
- {
- Q_OBJECT
- void aSignal();
- protected:
- void run() {
- emit aSignal();
- }
- };
- /* ... */
- Thread thread;
- Object obj;
- QObject::connect(&thread, SIGNAL(aSignal()), &obj, SLOT(aSlot()));
- thread.start();
另外一个常见的错误是:
- class Thread : public QThread
- {
- Q_OBJECT
- slots:
- void aSlot() {
- /* ... */
- }
- protected:
- void run() {
- /* ... */
- }
- };
- /* ... */
- Object obj;
- QObject::connect(&obj, SIGNAL(aSignal()), &thread, SLOT(aSlot()));
- thread.start();
- obj.emitSignal();
这里的obj
发出aSignal()
信号时,使用哪种连接方式?答案是:直接连接。因为Thread
对象所在线程发出了信号,也就是信号发出的线程与接受者是同一个。在aSlot()
槽函数中,我们可以直接访问Thread
的某些成员变量,但是注意,在我们访问这些成员变量时,Thread::run()
函数可能也在访问!这意味着二者并发进行:这是一个完美的导致崩溃的隐藏bug。
另外一个例子可能更为重要:
这个例子也会使用队列连接。然而,这个例子比上面的例子更具隐蔽性:在这个例子中,你可能会觉得,Object
所在Thread
所代表的线程中被创建,又是访问的Thread
自己的成员数据。稍有不慎便会写出这种代码。
为了解决这个问题,我们可以这么做:Thread
构造函数中增加一个函数调用:moveToThread(this)
:
- class Thread : public QThread {
- Q_OBJECT
- public:
- Thread() {
- moveToThread(this); // 错误!
- }
- /* ... */
- };
实际上,这的确可行(因为Thread
的线程依附性被改变了:它所在的线程成了自己),但是这并不是一个好主意。这种代码意味着我们其实误解了线程对象(QThread
子类)的设计意图:QThread
对象不是线程本身,它们其实是用于管理它所代表的线程的对象。因此,它们应该在另外的线程被使用(通常就是它自己所在的线程),而不是在自己所代表的线程中。
上面问题的最好的解决方案是,将处理任务的部分与管理线程的部分分离。简单来说,我们可以利用一个QObject
的子类,使用QObject::moveToThread()
改变其线程依附性:
- class Worker : public QObject
- {
- Q_OBJECT
- public slots:
- void doWork() {
- /* ... */
- }
- };
- /* ... */
- QThread *thread = new QThread;
- Worker *worker = new Worker;
- connect(obj, SIGNAL(workReady()), worker, SLOT(doWork()));
- thread->start();