多线程场景下Popen使用preexec_fn的风险成因及使用问题咨询

问题解答 #

1. 「存在线程」的指向 #

警告中提到的「存在线程」指的是调用subprocess.Popen的父进程（即你的应用本身），和通过Popen启动的子进程是否存在线程无关。

2. 死锁风险的成因 #

这个风险是类Unix系统fork()机制的固有特性导致的：

当父进程运行有多个线程时，调用fork()生成子进程的瞬间，子进程仅会继承当前发起fork调用的线程的执行状态，父进程的其他线程不会在子进程中启动，但父进程内所有线程持有的锁（包括libc内部锁、Python解释器的内存分配锁、第三方库的全局锁等）的状态会被完整复制到子进程中。
preexec_fn的执行窗口是fork()完成后、exec()执行目标程序前，此时子进程还运行在从父进程复制来的地址空间中。如果preexec_fn中的操作尝试获取已经被父进程其他线程持有的锁，没有任何线程会释放这个锁，就会直接陷入永久等待，也就是死锁。

3. 你的使用场景的风险评估 #

仅在preexec_fn中调用resource.setrlimit()设置虚拟内存软限制的场景，绝大多数情况下不会触发死锁：
resource.setrlimit()是纯系统调用，本身不会申请任何用户态全局锁，只要你没有在preexec_fn中执行其他操作（比如动态内存分配、打印日志、调用Python标准库中不属于异步信号安全的接口），就不会出现锁冲突。
如果你的运行环境支持Python 3.9及以上版本，更推荐直接使用subprocess.Popen内置的rlimit_as参数设置虚拟内存限制，完全不需要使用preexec_fn，从根源上规避风险。

内容的提问来源于stack exchange，提问作者Tarun R。