跨线程的信号与槽

我们如何应用驻足在其他线程里的QObject方法呢？Qt提供了一种非常友好而且干净的解决方案：向事件队列post一个事件，事件的处理将以调用我们所感兴趣的方法为主（当然这需要线程有一个正在运行的事件循环）。而触发机制的实现是由moc提供的内省方法实现的（译者注：有关内省的讨论请参见我的另一篇文章Qt的内省机制剖析）：因此，只有信号、槽以及被标记成Q_INVOKABLE的方法才能够被其它线程所触发调用。

静态方法QMetaObject::invokeMethod() 为我们做了如下工作：

QMetaObject::invokeMethod(object, "methodName",  

Qt::QueuedConnection,  
Q_ARG(type1, arg1),  
Q_ARG(type2, arg2));

 

请注意，因为上面所示的参数需要被在构建事件时进行硬拷贝，参数的自定义型别所对应的类需要提供一个共有的构造函数、析构函数以及拷贝构造函数。而且必须使用注册Qt型别系统所提供的qRegisterMetaType() 方法来注册这一自定义型别。

跨线程的信号槽的工作方式相类似。当我们把信号连接到一个槽的时候，QObject::connect的第五个可选输入参数用来特化这一连接类型：

direct connection 是指：发起信号的线程会直接触发其所连接的槽；

queued connection 是指：一个事件被派发到接收者所在的线程中，在这里，事件循环会之后的某一时间将该事件拾起并引起槽的调用；

blocking queued connection 与queued connection的区别在于，发送者的线程会被阻塞，直至接收者所在线程的事件循环处理发送者发送（入栈）的事件，当连接信号的槽被触发后，阻塞被解除；

automatic connection (缺省默认参数) 是指： 如果接收者所依附的线程和当前线程是同一个线程，direct connection会被使用。否则使用queued connection。

请注意，在上述四种连接方式当中，发送对象驻足于哪一个线程并不重要！对于automatic connection，Qt会检查触发信号的线程，并且与接收者所驻足的线程相比较从而决定到底使用哪一种连接类型。特别要指出的是：当前的Qt文档的声明(4.7.1) 是错误的：

如果发射者和接受者在同一线程，其行为与Direct Connection相同；，如果发射者和接受者不在同一线程，其行为Queued Connection相同

因为，发送者对象的线程依附性在这里无关紧要。举例子说明

view plaincopy to clipboardprint?
class Thread : public QThread  

{  
Q_OBJECT  
signals:  
void aSignal();  
protected:  

void run() {  
emit aSignal();  
}  
};  
/* ... */  

Thread thread;  
Object obj;  

QObject::connect(&thread, SIGNAL(aSignal()), &obj, SLOT(aSlot()));  

thread.start();  
 

如上述代码，信号aSignal() 将在一个新的线程里被发射（由线程对象所代表）；因为它并不是Object 对象驻足的线程，所以尽管Thread对象thread与Object对象obj在同一个线程，但仍然是queued connection被使用。

（译者注：这里作者分析的很透彻，希望读者仔细揣摩Qt文档的这个错误。 也就是说 发送者对象本身在哪一个线程对与信号槽连接类型不起任何作用，起到决定作用的是接收者对象所驻足的线程以及发射信号（该信号与接受者连接）的线程是不是在同一个线程，本例中aSignal()在新的线程中被发射，所以采用queued connection）。

另外一个常见的错误如下：
class Thread : public QThread  

{  
Q_OBJECT  
slots:  
void aSlot() {  
/* ... */  
}  

protected:  
void run() {  
/* ... */  
}  
};  

/* ... */  
Thread thread;  
Object obj;  

QObject::connect(&obj, SIGNAL(aSignal()), &thread, SLOT(aSlot()));  

thread.start();  
obj.emitSignal();
 

当“obj”发射了一个aSignal()信号是，哪种连接将被使用呢？你也许已经猜到了：direct connection。这是因为Thread对象实在发射该信号的线程中生存。在aSlot()槽里，我们可能接着去访问线程里的一些成员变量，然而这些成员变量可能同时正在被run()方法访问：这可是导致完美灾难的秘诀。可能你经常在论坛、博客里面找到的解决方案是在线程的构造函数里加一个moveToThread(this)方法。

class Thread : public QThread {
  
Q_OBJECT

  
public:
  
Thread() {
  
moveToThread(this); // 错误

  
}
  
/* ... */
  
};

（译注：moveToThread(this)）

 

这样做确实可以工作(因为现在线程对象的依附性已经发生了改变），但这是一个非常不好的设计。这里的错误在于我们正在误解线程对象的目的（QThread子类）：QThread对象们不是线程；他们是围绕在新产生的线程周围用于控制管理新线程的对象，因此，它们应该用在另一个线程（往往在它们所驻足的那一个线程）

一个比较好而且能够得到相同结果的做法是将“工作”部分从“控制”部分剥离出来，也就是说，写一个QObject子类并使用QObject::moveToThread()方法来改变它的线程依附性： 

view plaincopy to clipboardprint?

class Worker : public QObject  
{  
Q_OBJECT  
public slots:  

void doWork() {  
/* ... */  
}  
};  
/* ... */  

QThread thread;  
Worker worker;  

connect(obj, SIGNAL(workReady()), &worker, SLOT(doWork()));  

worker.moveToThread(&thread);  
thread.start();
 

我应该什么时候使用线程
当你不得不使用一个阻塞式API时


当你需要（通过信号和槽，或者是事件、回调函数）使用一个没有提供非阻塞式API的库或者代码时，为了阻止冻结事件循环的唯一可行的解决方案是开启一个进程或者线程。由于创建一个新的进程的开销显然要比开启一个线程的开销大，后者往往是最常见的一种选择。

这种API的一个很好的例子是地址解析 方法（只是想说我们并不准备谈论蹩脚的第三方API, 地址解析方法它是每个C库都要包含的）,它负责将主机名转化为地址。这个过程涉及到启动一个查询（通常是远程的）系统：域名系统或者叫DNS。尽管通常情况下响应会在瞬间发生，但远程服务器可能会失败：一些数据包可能会丢失，网络连接可能断开等等。简而言之，我们也许要等待几十秒才能得到查询的响应。

UNIX系统可见的标准API只有阻塞式的（不仅过时的gethostbyname(3)是阻塞式的,而且更新的getservbyname(3) 以及getaddrinfo(3)也是阻塞式的）。QHostInfo [doc.qt.nokia.com], 它是一个负责处理域名查找的Qt类，该类使用了QThreadPool 从而使得查询可以在后台进行）（参见here [qt.gitorious.com]）；如果屏蔽了多线程支持，它将切换回到阻塞式API).

另一个简单的例子是图像装载和放大。QImageReader [doc.qt.nokia.com] 和QImage [doc.qt.nokia.com]仅仅提供了阻塞式方法来从一个设备读取图像，或者放大图像到一个不同的分辨率。如果你正在处理一个非常大的图像，这些处理会持续数（十)秒。