【问题标题】:Gracefull python joblib killGracefull python joblib kill
【发布时间】:2017-07-30 20:13:43
【问题描述】:

是否可以优雅地终止 joblib 进程(线程后端),并且仍然返回到目前为止的计算结果?

parallel = Parallel(n_jobs=4, backend="threading")
result = parallel(delayed(dummy_f)(x) for x in range(100))

目前我想出了两个解决方案

  • parallel._aborted = True 等待启动的工作完成(在我的情况下它可能很长)
  • parallel._terminate_backend() 如果作业仍在管道中,则挂起(parallel._jobs 不为空)

有没有办法解决这个问题?

【问题讨论】:

  • 您能为您的每个解决方案举一个例子吗?
  • 好吧,我会试着花点时间记录一下。抱歉,迟来的回复:)

标签: python joblib


【解决方案1】:

据我所知,Joblib 不提供杀死生成线程的方法。 由于每个子线程都在自己的上下文中运行,因此实际上很难执行优雅的终止或终止。 话虽如此,有一个可以采用的解决方法。

模仿.join()(线程)功能(一种):

  1. 创建一个共享内存shared_dict,其键对应每个线程ID,值是否包含线程输出或异常,例如:

    shared_dict = {i: None for i in range(num_workers)}

  2. 当任何线程中出现错误时,通过处理程序捕获异常,而不是立即引发异常,而是将其存储在共享内存标志中

  3. 创建一个等待all(shared_dict.values())的异常处理程序

  4. 在所有值都填充了结果或错误后,通过引发错误或记录或其他方式退出程序。

【讨论】:

  • 您好,感谢您的回复!对,afaik joblib 的行为已经有点像这样,将结果存储在共享地图中,并在完成时返回。我遇到的问题是想要在生成的线程完成之前停止它们。 joblib 提供的 api 不允许(不是吗?)在不破解私有函数的情况下允许这样做。我最终破解了它以使其工作,但我仍然需要花一些时间来记录它。
  • 嗨,你是对的,它应该以这种方式工作,但在 UWSGI 应用程序部署环境中,Joblib 可能会搞砸。我遇到了这个问题,因为多个错误处理程序相互堆叠。在我的情况下,当任何工作人员引发错误时,它会使用引发端点错误,但由于在 Joblib 可以等待其他工作人员完成之前引发错误,它只是暂停剩余的工作人员并在下一个请求到来时恢复它们,这会引发奇怪的运行时错误因为在之前的请求中进行了清理。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2016-09-29
  • 2021-10-05
  • 1970-01-01
  • 1970-01-01
  • 2017-03-04
  • 2018-03-21
  • 2013-10-15
相关资源
最近更新 更多