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. 图解对比
| 状态 | 线程行为 | 事件处理情况 |
| 空闲/标准状态 | 循环执行exec() | 正常。像前台文员，每干完一个杂活就看一眼信箱。 |
| 你的死循环状态 | 循环执行decode() | 失效。像流水线工人，手一直在动，即使信箱塞满了，他也看不见。 |
4. 为什么“直接调用”和“原子变量”能解决？
当你把QueuedConnection改成在主线程直接调用worker->setPaused(true)时：
不走邮箱：主线程直接冲进子线程的房间，强行修改了桌子上的一个开关（
std::atomic<bool> m_paused）。瞬间生效：此时子线程虽然还在
while循环里转圈，但它下一圈跑到waitIfPaused()这行代码时：void waitIfPaused() { if (m_paused.load()) { // 这里它读到了主线程刚改掉的开关！ // 乖乖进入阻塞等待状态 } }结果：子线程被“绊了一跤”，停在了原地。
总结
子线程不是“不执行”事件循环，而是它被你写的while循环给“绑架”了，导致它根本没有机会运行到 Qt 框架提供的那个负责处理事件的while循环里。
这也是为什么在处理密集型计算（如音视频解码、大文件读取）时，我们必须使用原子变量 (Atomic)或互斥量 (Mutex)来进行跨线程的“硬控制”，而不是依赖“软绵绵”的异步信号。