我们有一个在python 3.2(Fedora Core 14 64b)中运行的Web服务服务器,但由于新的依赖(没有3.2支持),它们被迫反向移植到python 2.6.7。有一部分代码使用了已经重写的并发期货,以便使用multiprocessing.Pool并行执行几个关键部分。代码现在看起来像这样:
import multiprocessing
def _run_threads(callable_obj, args, threads):
pool = multiprocessing.Pool(processes=threads)
process_list = [pool.apply_async(callable_obj, a) for a in args]
pool.close()
pool.join()
return [x.get() for x in process_list]
对滥用名称“线程”的混淆道歉。这些是流程。
自实现此功能以来,我们发现它有时会挂起。当我们最终杀死父(主)进程时,我们得到一个乱码回溯;但有几条线似乎很关键:
[snip]
Process PoolWorker-445:
[snip]
File "/usr/lib64/python2.6/multiprocessing/pool.py", line 59, in worker
task = get()
File "/usr/lib64/python2.6/multiprocessing/queues.py", line 352, in get
return recv()
racquire()
[snip]
在我看来,从现有证据来看,池中的子进程未能从父进程接收到“关闭”信号,因此它正在等待工作。父母坐着等孩子关门。服务器挂起。这种情况不确定,但对于这样一个关键服务器来说太频繁了(每天一次)。
run_threads()函数的编码有问题吗?这是一个已知的解决问题吗?显然,我们使用它来进行时间关键处理,因此除非绝对必要,否则我们不希望重新编码顺序执行。坚持多处理的原因之一.Pool可以轻松访问并行运行的返回代码。
由于