[Bug已解决] Codex TUI 一轮结束后闲置 30-90 秒线程 parked事件循环空转解决方案一、现象长什么样你用 Codex 的TUI终端界面。每完成「一轮turn」对话/任务后界面整个卡住fully idle30~90 秒之后才恢复。排查发现所有工作线程都「parked停在那等」不是网络卡、也不是死锁锁没被占。即 GitHub Issues (openai/codex) #31401Codex TUI sometimes goes fully idle for 30-90s after a turn completes (all threads parked, not network/lock related)。 本质是一轮结束后应有「唤醒信号」让线程/事件循环继续处理下一轮或响应用户但这个唤醒信号丢了/迟到了**导致所有线程在「等一个永远不会来的通知」上空转直到某个超时30-90s兜底才恢复**。这是通用的「事件循环/线程池的完成通知丢失lost wakeup」问题属于livelock / 伪空闲不是死锁。 本文聚焦通用技术为什么一轮结束后线程会全部 parked完成通知丢失、lost wakeup 与条件变量的正确用法、以及用「超时兜底 正确 notify」消除长时间闲置。用真实可运行 Python 代码说明不依赖具体产品。二、背景线程 parked 但没死锁先区分死锁deadlock线程 A 等锁 L1被 B 占B 等锁 L2被 A 占→ 永久卡无超时也回不来parked / 伪空闲这里的情况所有线程在condition.wait()上等一个「完成通知」。通知本该在一轮结束时notify_all()但没发出来lost wakeup于是线程干等。区别是通常这种等待带超时超时后线程醒来处理所以 30-90s 后恢复而不是永远卡。 「不是 network/lock related」说明不是网络慢、也不是锁互相等待而是**「完成事件没正确唤醒等待者」**——纯粹的调度/通知 bug。三、为什么一轮结束会「全员 parked」典型机制TUI 有个事件循环 工作线程池。一轮结束时主任务完成应condition.notify_all()唤醒等待下一轮/UI 刷新的线程但通知逻辑有竞态通知在「最后一个等待者进入 wait 之前」就发了 →等待者错过了通知lost wakeup之后没人再 notify → 全员 park 等超时或通知只发给了「错误的条件变量」/ 错误的线程集合或一轮结束的清理逻辑提前 return没走到 notify。 于是所有线程在wait(timeout30~90s)上空转直到超时兜底才醒。用户看到「界面死 30-90 秒」。四、最小可运行lost wakeup 复现与修复下面演示「通知在等待者就位前发出 → lost wakeup → 长时间 park」以及「正确加锁 超时兜底」修复import threading, time # ❌ 错误可能 lost wakeup通知早于 wait cond threading.Condition() done False def worker_bad(): global done with cond: while not done: cond.wait(60) # 等最多 60s若 notify 在 wait 前发了 → 错过 def finish_turn_bad(): global done done True # 风险若 worker 还没进入 wait这里 notify 白发 → lost wakeup with cond: cond.notify_all() # ✅ 正确通知必须在「持有同一锁 状态已置位」下进行等待者检查状态 def worker_good(): with cond: while not done: # 带超时兜底绝不永久 park cond.wait(2) # 短超时最多 2s 恢复 def finish_turn_good(): with cond: done True cond.notify_all() # 持锁通知等待者醒来必看到 doneTrue要点notify必须在持有同一把锁、且共享状态已更新后调用等待者醒来先检查状态while 而非 if才能避免 lost wakeup。再加短超时兜底防极端丢失。五、解决方案一正确用条件变量核心修复「一轮结束唤醒」的铁律import threading class TurnScheduler: def __init__(self): self.lock threading.Condition() self.turn_done False def on_turn_complete(self): with self.lock: self.turn_done True # 持锁 状态已置 notify等待者醒来必看到 turn_done self.lock.notify_all() def wait_next(self): with self.lock: while not self.turn_done: # 短超时兜底避免任何 lost wakeup 导致长时间 park self.lock.wait(timeout1.0) self.turn_done False # 重置准备下一轮关键三点持锁 notify、状态先行、while 检查状态——这是条件变量的标准正确用法杜绝 lost wakeup。六、解决方案二短超时兜底防御 lost wakeup即使逻辑正确极端竞态仍可能丢通知。用短超时让线程定期醒来自查def wait_next_safe(self): with self.lock: while not self.turn_done: self.lock.wait(timeout0.5) # 最多 0.5s 醒一次自查 self.turn_done False超时从 30-90s 降到 0.5s即使通知丢了最多 0.5s 也自愈用户完全感知不到闲置。这是消除「长时间 idle」最直接的有效手段。七、解决方案三事件循环用「显式唤醒」而非被动等若 TUI 用事件循环asyncio一轮结束应显式event.set()/loop.call_soon唤醒而非依赖被动轮询import asyncio async def turn_loop(): turn_done asyncio.Event() while True: await do_turn() turn_done.set() # 显式唤醒等待者 turn_done.clear() # 下一轮asyncio.Event的set()不会「lost」——它的语义是「置位后一直有效直到 clear」等待者醒来必看到已置位天然防 lost wakeup比 Condition 更安全。优先用Event/Future而非手写 Condition。八、解决方案四诊断闲置区分死锁 vs 伪空闲排查时若30-90s 后自动恢复→ 是伪空闲/lost wakeup有超时兜底不是死锁若永不恢复→ 才是死锁用线程 dump /faulthandler看所有线程卡在cond.wait而非lock.acquire→ 确认是 parked 等通知日志在一轮结束时打印「notify 已发」等待者打印「收到唤醒」对比是否漏发。import faulthandler faulthandler.dump_traceback_later(30, exitFalse) # 30s 后打线程栈看卡哪九、排查清单TUI 一轮后闲置一轮后空转 30-90s 后恢复、线程全 parked、非网络/锁 → lost wakeup 伪空闲#31401 类。条件变量正确用持锁 notify 状态先行 while 检查状态防 lost wakeup。短超时兜底wait(timeout0.5) 而非 30-90s丢通知也 0.5s 自愈。优先 Event/Futureasyncio.Event 置位语义天然防 lost wakeup。诊断faulthandler 线程栈看卡在 cond.wait非死锁日志对比 notify 是否漏发。测试模拟「notify 早于 wait」竞态验证不长时间 park。十、小结Codex TUI sometimes goes fully idle for 30-90s after a turn completes (all threads parked, not network/lock related)openai/codex #31401的本质是一轮结束后唤醒「下一轮/UI 刷新等待者」的通知信号丢失lost wakeup——通知在等待者进入 wait 前就发了或根本没发导致所有线程在condition.wait(timeout30~90s)上空转直到超时兜底才恢复。这是 livelock/伪空闲不是死锁锁没互占。 通用解决方案适用于任何「线程池/事件循环等待完成通知」的系统条件变量正确用持锁notify 共享状态先置位 while检查状态杜绝 lost wakeup短超时兜底wait(timeout0.5)而非 30-90s丢通知也立刻自愈用户无感优先 Event/Futureasyncio.Event置位语义天然防 lost wakeup比手写 Condition 安全诊断faulthandler线程栈确认卡在wait非死锁日志对比 notify 是否漏发。 记住「全员 parked 但会超时恢复」是 lost wakeup通知丢了不是死锁。条件变量必须持锁 notify 状态先行 while 检查再加短超时兜底才能消除长时间闲置。