关于Qt::BlockingQueuedConnection的死锁问题

绑定信号槽时，如果信号对象和槽对象属于不同的线程，通过Qt::BlockingQueuedConnection可以实现同步调用，即发送信号的代码等待槽函数返回才继续运行

文档的说明：

Qt::QueuedConnection
The slot is invoked when control returns to the event loop of the receiver’s thread. The slot is executed in the receiver’s thread.
Qt::BlockingQueuedConnection
Same as Qt::QueuedConnection, except that the signalling thread blocks until the slot returns. This connection must not be used if the receiver lives in the signalling thread, or else the application will deadlock.

这里有一种情况需要特别注意，假设UI线程为A，工作线程为B，发送信号的代码运行于线程B，但声明信号的对象属于线程A，此时会造成死锁，什么场景会产生？
例如UI线程创建了信号对象S，该对象有一个函数S::Process，内部会发送信号sigDone，绑定了sigDone和UI线程的槽函数。然后通过QtConcurrent调用了S::Process，虽然S::Process实际运行于QtConcurrent的线程，但对象S属于UI线程，调用sigDone时就会死锁。
所以，识别Qt::BlockingQueuedConnection是否会死锁，根本在于判断connect时发送对象所属的线程是否不同于接收对象线程，而不是发送信号（emit XXX这一句代码）时所在的线程！
解决办法是通过QObject::moveToThread改变信号对象所属线程，你可以通过QObject::thread查看当前对象所属的线程