Qt多线程阻塞：为何信号失效？

这个问题问到了 Qt 多线程编程的核心机制。简单来说，是因为“一个线程在同一时刻只能做一件事”。

为了让你彻底理解，我们把线程想象成一个**“办事员”，把事件循环想象成他的“工作手册”**。

1. 正常的“事件驱动”模式

在正常的 Qt 线程中，办事员的操作流程是这样的（这就是exec()内部做的事）：

// 简化版的事件循环逻辑 (QEventLoop) while (true) { // 1. 检查有没有新邮件（信号、定时器、鼠标点击等事件） Event e = waitNextEvent(); // 2. 拆开邮件，根据指令去干活 processEvent(e); // 3. 干完活了，回到第 1 步继续等 }

在这种情况下，办事员大部分时间都在等邮件。一旦你从主线程发一个QueuedConnection的信号，就相当于给他的邮箱丢了一封信。他处理完手头的微小工作后，马上就会拆信并执行setPaused(true)。

2. 为什么你的while循环堵死了它？

当你的代码进入了while(!m_stop)这种大循环（解码循环）时，办事员的状态变成了这样：

void VideoWorker::startDecode() { // 办事员进入了这个房间，并反锁了门 while (!m_stop) { // A. 解码一帧视频 // B. 计算同步时间 // C. 渲染画面 // ... 他在这个循环里转圈圈，永远回不到上面的“检查邮件”步骤 } }

关键点在于：

• 邮箱在门外：Qt::QueuedConnection投递的事件是放在该线程的**事件队列（邮箱）**里的。

• 没空收信：办事员（子线程）正忙着在while循环里“解码”，只要这个while循环不结束，他就没有机会回到事件循环的processEvent()阶段去开邮箱。

• 后果：你的暂停指令（邮件）就一直堆在邮箱里，直到while循环因为某种原因（比如播放结束）退出了，他才会去开箱，但那时候暂停已经没意义了。

3. 图解对比

4. 为什么“直接调用”和“原子变量”能解决？

当你把QueuedConnection改成在主线程直接调用worker->setPaused(true)时：

1. 不走邮箱：主线程直接冲进子线程的房间，强行修改了桌子上的一个开关（std::atomic<bool> m_paused）。

2. 瞬间生效：此时子线程虽然还在while循环里转圈，但它下一圈跑到waitIfPaused()这行代码时：

   void waitIfPaused() { if (m_paused.load()) { // 这里它读到了主线程刚改掉的开关！ // 乖乖进入阻塞等待状态 } }

3. 结果：子线程被“绊了一跤”，停在了原地。

总结

子线程不是“不执行”事件循环，而是它被你写的while循环给“绑架”了，导致它根本没有机会运行到 Qt 框架提供的那个负责处理事件的while循环里。

这也是为什么在处理密集型计算（如音视频解码、大文件读取）时，我们必须使用原子变量 (Atomic)或互斥量 (Mutex)来进行跨线程的“硬控制”，而不是依赖“软绵绵”的异步信号。