【发布时间】:2012-10-10 15:27:03
【问题描述】:
对于问题 6721,在 Linux 中的同一 python 应用程序中使用多处理和用户线程的最佳做法或解决方法是什么,python 标准库中的锁应该在 fork 上进行清理?
为什么我需要两者?我使用子进程进行繁重的计算,产生的数据结构结果太大而无法通过队列返回——而是必须立即将它们存储到磁盘。让这些子进程中的每一个由一个单独的线程监控似乎很有效,这样当完成时,线程可以处理将大(例如,多 GB)数据读回需要结果以进行进一步计算的进程的 IO结合其他子进程的结果。 子进程会间歇性地挂起,我刚刚(经过多次头部撞击)发现这是使用日志模块“引起”的。其他人在这里记录了这个问题:
https://twiki.cern.ch/twiki/bin/view/Main/PythonLoggingThreadingMultiprocessingIntermixedStudy
这指向了这个显然未解决的 python 问题:python 标准库中的锁应该在 fork 上进行清理; http://bugs.python.org/issue6721
我对追踪这件事的困难感到震惊,我回答:
Are there any reasons not to mix Multiprocessing and Threading module in Python
带有对“小心”的相当无益的建议和指向上述内容的链接。
但是关于:Issue 6721 的冗长讨论表明,在同一应用程序中同时使用多处理(或 os.fork)和用户线程是一个“错误”。由于我对这个问题的理解有限,我在讨论中发现太多分歧,无法得出在同一应用程序中同时使用多处理和线程的解决方法或策略是什么。我的直接问题通过禁用日志记录得到解决,但我在父进程和子进程中创建了少量其他(显式)锁,并且怀疑我正在为进一步的间歇性死锁设置自己。
在 python (2.7,3.2,3.3) 应用程序中使用线程和多处理时,您能否给出实用的建议来避免在使用锁和/或日志记录模块时出现死锁?
【问题讨论】:
-
有趣的是
multiprocessing模块已经在内部使用treading模块来创建一些分叉感知类型(包括锁类型)。见util.py。这些类型用于来自manager.py的BaseProxy类。
标签: python multithreading logging multiprocessing locks