多线程程序中preexec_fn是否可安全使用？适用场景有哪些？

已知使用subprocess.Popen(..., preexec_fn=func)存在线程不安全问题，多线程程序中调用可能触发子进程死锁，官方文档明确给出警告：

警告：当应用程序中存在线程时，使用preexec_fn参数是不安全的。子进程可能在调用exec之前发生死锁。如果必须使用该参数，请保证其逻辑尽可能简单！尽量减少调用的库函数数量。

核心结论先放前面：多线程场景下不存在100%无死锁风险的preexec_fn用法，仅存在死锁概率极低、可满足工程可用性要求的有限场景。

死锁的根本原因 #

preexec_fn运行在fork()创建出的子进程中，且执行时机在exec()替换进程镜像之前。fork()的特性决定了：子进程会完整复制父进程的地址空间快照，但父进程中除了调用fork()的线程外，其余所有线程都会在子进程中直接终止消失。
所有这些消失的线程当时持有的锁——不管是Python解释器的GIL、glibc等系统库的内部锁（比如内存分配锁、IO缓冲区锁）、还是第三方C扩展的自定义锁——都会永久处于锁定状态，没有任何持有者会去释放它。只要preexec_fn里的逻辑尝试获取任意一把这类被悬空持有的锁，子进程就会直接卡死，永远走不到后续的exec步骤。

不同类型preexec_fn的实际风险 #

• 纯Python实现的函数（哪怕是lambda: os.nice(20)这类极简逻辑）：存在明确死锁风险，不建议使用
  不要觉得逻辑简单就不会出问题：虽然CPython在fork返回后、执行preexec_fn之前，会调用PyOS_AfterFork_Child()（旧版本为PyOS_AfterFork()）重置解释器内部的锁包括GIL，但这个操作覆盖不到C库和第三方扩展的锁。
  哪怕是一行os.nice(20)的Python调用，执行过程中也会涉及参数解析、临时对象创建，这些步骤会调用glibc的内存分配函数。如果fork发生的瞬间，父进程里其他线程刚好持有malloc相关的锁，子进程里的内存分配调用就会直接死锁，没有任何侥幸空间。
• 满足严格约束的C编译扩展函数：风险极低，属于工程可用场景
  这里的约束没有任何妥协空间：
  • 函数全程不能调用Python C API，不能尝试获取GIL，完全不触碰Python解释器状态
  • 函数内部只能调用POSIX标准规定的异步信号安全函数，不能调用malloc、标准IO函数、线程操作类函数等非异步信号安全的接口——这类接口内部的锁不会被CPython的fork后处理逻辑重置，只要fork时锁被其他线程持有，调用就会卡死。
    如果你写的C函数完全符合上述要求，比如仅直接发起nice系统调用调整进程优先级，没有任何额外逻辑，那死锁概率几乎可以忽略，是可以在多线程环境下使用的。

更推荐的替代方案 #

Python 3.2之后，绝大多数常见的preexec_fn使用场景都已经有了原生参数支持，完全不需要自己写preexec_fn承担死锁风险：

• 调整进程优先级：使用prio参数
• 切换工作目录：使用cwd参数
• 重置信号处理规则：使用默认开启的restore_signals参数
• 关闭多余文件描述符：使用close_fds=True，3.9及以上版本可配合pass_fds精确指定需要保留的文件描述符
• 切换执行用户/用户组：使用user、group、extra_groups参数
  如果确实有特殊逻辑必须在fork后、exec前执行，优先检查是否能用上述原生参数覆盖，覆盖不了再考虑编写符合严格约束的C扩展，绝对不要用纯Python函数作为preexec_fn。

补充说明：本文讨论基于近期版本的Glibc运行环境。即使是新版Glibc，也无法在多线程进程fork后自动重置所有C库内部锁，pthread_atfork注册的钩子仅能覆盖非常有限的场景，更不可能覆盖第三方库持有的锁，因此不存在绝对安全的preexec_fn用法，只有风险高低的区别。

内容的提问来源于stack exchange，提问作者Błażej Michalik