[Bug已解决] 从旧会话-fork-进-worktree-前卡在创建子线程-fork-与线程安全方案

[Bug已解决] 从旧会话 fork 进 worktree 前卡在创建子线程fork 与线程安全解决方案一、现象长什么样你的应用有个功能从「上一次对话 / 任务」fork 出一个新的隔离工作区git worktree在新 worktree 里继续干活。实现上它用os.fork()或类似 fork 机制来复制进程状态、再在新 worktree 里干活。但你发现fork 之后、还没真正创建子线程child thread干活时进程就卡死了stall。 即 GitHub Issues (openai/codex) #31418Fork from earlier turn into worktree stalls before creating child thread。 本质是在「已有多个线程运行」的进程里调用fork()是 POSIX 著名的危险操作——fork 只复制「调用 fork 的那个线程」但进程里其它线程持有的锁mutex不会被释放于是子进程里任何想拿那个锁的操作都会永久死锁。应用在 fork 后准备创建子线程/干活时撞上了某个被「其它线程持有、fork 后永不释放」的锁 → 卡死。 本文聚焦通用技术为什么 fork 多线程会死锁、fork后只复制调用线程的后果、以及如何安全地「分叉状态 在新环境干活」用fork仅在单线程态、或用spawn/exec、multiprocessing规避。用真实可运行代码说明。二、背景fork 只复制调用线程POSIXfork()的语义子进程是父进程的副本但只复制「调用 fork() 的线程」。父进程里其它线程不会出现在子进程里。 危险点在于锁mutex假设父进程有线程 A 拿着一个全局锁L正在干活此时主线程调用fork()子进程里锁L的状态是「被锁住」复制了父的内存状态但持有 L 的线程 A 不在子进程里子进程里某段代码想L.lock()→ 永远等不到释放 →死锁stall。 这就是经典的「fork 之后只能调用 async-signal-safe 函数不能碰任何可能加锁的库」规则如malloc内部有锁fork 后调用malloc可能死锁。三、为什么「fork 进 worktree 前卡住」具体到这个 bug应用 fork 当前会话状态可能父进程已经起了多个后台线程UI 线程、网络线程、日志线程……。fork 后子进程想切到新 worktree 目录创建子线程去干活。 但第 1/2 步里子进程需要拿某个锁比如 Python 的 import 锁、logging 锁、或应用自己的全局状态锁而那个锁正被「父进程里某个不存在于子进程的线程」持有 → 子进程永久等锁 → 卡在「创建子线程之前」。 即fork 发生在多线程环境下子进程继承了「悬空锁」任何加锁操作都死锁。这完全符合 POSIX 的 fork 陷阱。四、最小可运行复现 fork 锁死锁下面用 Python 演示「父有线程持锁 → fork → 子想加锁 → 死锁」用threadingos.forkimport os, threading, time lock threading.Lock() def holder(): # 线程 A 长期持有锁 with lock: time.sleep(1000) def child_wants_lock(): # 子进程里想拿同一个锁 → 死锁持有者线程不在子进程 lock.acquire() print(子进程拿到锁永远不会到这里) lock.release() if __name__ __main__: t threading.Thread(targetholder, daemonTrue) t.start() time.sleep(0.1) # 确保 A 拿到锁 pid os.fork() if pid 0: # 子进程调用 child_wants_lock 会卡死 child_wants_lock() # STALL锁被父线程 A 持有A 不在子进程 else: print(父进程继续) time.sleep(2) print(子进程应已卡死)要点fork 后子进程里任何加锁操作若锁被「不存在于子进程的线程」持有就死锁。这正是 #31418 的根因。五、解决方案一fork 仅在「单线程态」进行最安全原则只在程序还没起任何后台线程时 fork比如进程启动最早期、或专门设计一个「fork 前先停掉所有线程」的序列。import os, threading # 错误在已有后台线程时 fork见第四节 # 正确fork 前确保没有其它线程持锁 def fork_safe(): # 1. 停掉所有后台线程join确保无悬空锁 for t in list_running_threads(): if t is not threading.current_thread(): t.join(timeout5) # 2. 此刻只有当前线程fork 安全 pid os.fork() return pid但应用通常在「运行中途」想 fork从旧会话建 worktree此时已有线程——所以「先停所有线程」不现实。于是请看方案二。六、解决方案二用 spawn / exec 替代 fork推荐更安全不要用fork()复制当前进程而是用exec启动一个全新的干净进程把需要的状态通过参数/文件/管道传过去import subprocess, os, json def create_worktree_child(state_path, worktree_path): # 不 fork 当前多线程进程而是 exec 一个全新 Python 进程 # 状态通过文件传递而非内存复制 subprocess.Popen([ python, -m, myapp.worktree_worker, --state, state_path, --worktree, worktree_path, ]) # 新进程是全新的无悬空锁可安全起子线程 # 父进程把「要 fork 的会话状态」序列化到文件 with open(state_path, w) as f: json.dump(session_state, f) create_worktree_child(state_path, /path/to/worktree)新进程从零启动线程都是它自己建的没有「父线程持有的悬空锁」彻底规避 fork 死锁。七、解决方案三用 multiprocessing它默认用 spawn on macOS/Winfork 谨慎multiprocessing在不同平台默认启动方式不同Linux 默认fork仍有前述陷阱macOS/Windows 默认spawn安全全新进程。 显式指定spawn规避import multiprocessing as mp def work(state, worktree): # 在新进程里干活spawn 启动无悬空锁 pass ctx mp.get_context(spawn) # 强制 spawn避开 fork 陷阱 p ctx.Process(targetwork, args(state, worktree)) p.start()spawn会重新 import 主模块、重建进程不会继承父的多线程锁状态安全。八、解决方案四fork 后立即 execforkexec 模式若必须用 fork比如要精确复制父状态遵循经典fork()后立即exec()模式——子进程 fork 后不做任何加锁操作直接exec一个干净程序import os pid os.fork() if pid 0: # 子进程fork 后只做 async-signal-safe 的事立刻 exec os.execv(/usr/bin/python3, [python3, worker.py, state_path]) # exec 后子进程镜像被新程序替换悬空锁消失 else: os.waitpid(pid, 0)exec把子进程替换成全新程序映像所有内存/锁状态清零规避死锁。代价父状态不能直接内存共享需通过文件/管道传。九、排查清单fork 后卡死从运行中的多线程会话 fork 后卡死且在创建子线程/加锁前 → fork 悬空锁死锁#31418 类。复现根因fork 只复制调用线程其它线程持有的锁在子进程永不释放 → 子进程加锁死锁。方案一fork 仅在单线程态不现实于运行中途方案二用exec/spawn启全新进程状态用文件/管道传无悬空锁方案三multiprocessing显式get_context(spawn)方案四fork()后立即exec()子进程镜像替换清锁。十、小结Fork from earlier turn into worktree stalls before creating child threadopenai/codex #31418的本质是应用在「已有多个后台线程」的进程里调用fork()来复制会话状态进新 worktree。但 POSIXfork()只复制「调用 fork 的线程」其它线程持有的锁在子进程里变成「悬空锁、永不释放」。子进程后续任何加锁操作包括创建子线程前的准备都永久死锁 → 卡死。 通用解决方案适用于任何「多线程进程里 fork」的场景规避 fork 复制用exec/spawn启动全新进程状态经文件/管道传递无悬空锁multiprocessing spawn显式get_context(spawn)跨平台安全forkexec 模式若必须 fork子进程 fork 后只做 async-signal-safe 操作并立即exec()替换映像清锁单线程 fork仅在确认无其它线程持锁时 fork运行中途不现实。 记住fork()只复制调用线程多线程进程里 fork 后子进程的锁是悬空的——任何加锁操作都会死锁。要复制状态用全新进程 显式传参别用 fork 复制多线程进程。