我们有一个运行在python3.2(Fedora core1464b)中的web服务服务器,但是由于一个新的依赖项(它不支持3.2),所以不得不将端口返回到python2.6.7。代码中有一段使用了concurrent futures,它被重写为使用多处理.池同时执行两个关键部分。代码现在如下所示:
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]
为混淆滥用“线程”这个名称而道歉。这些是进程。在
由于实现了这个函数,我们发现它有时会挂起。当我们最终终止父(主)进程时,我们会得到一个混乱的回溯;但是有几行似乎很关键:
^{pr2}$在我看来,从现有的证据来看,池中的一个子进程无法从父进程接收到“关闭”信号,因此它坐在那里等待工作。家长坐在那里等孩子关机。服务器挂起。这种情况是不确定的,但对于这样一个关键服务器来说太频繁了(每天一次)。在
run_threads()函数的编码是否有问题?这是已知的问题吗?显然,我们将其用于时间关键型处理,因此除非绝对必要,否则我们不希望为顺序执行重新编码。坚持的原因之一多处理.池是容易获取返回代码的操作并行运行。在
谢谢
我不知道这个问题的起源。这绝对是非常有趣的。然而,也许一点点重组就能解决问题。我认为在收集结果之前,您不需要终止池进程,对吗?{a1'可能有助于使用
或者,在您的情况下,在关闭/加入池之前调用
x.get() for x in process_list
。如果问题持续存在并发生在get()
期间,我们至少知道它与close()
无关。在相关问题 更多 >
编程相关推荐