【问题标题】:Is it ok to spawn threads in a wsgi-application?可以在 wsgi 应用程序中生成线程吗?
【发布时间】:2011-09-28 14:21:30
【问题描述】:

为了实现类似于谷歌应用程序引擎“延迟调用”的功能(即处理请求,然后处理延迟任务),我进行了一些实验并想出了一个解决方案来生成一个线程,其中我的延迟调用呼叫已处理。

我现在正在尝试确定这是否是一种可接受的方式。

是否有可能(根据 WSGI 规范)在处理实际请求之后,但在所有线程用完之前,该进程被网络服务器终止?

(如果有更好的方法也可以)

【问题讨论】:

  • 您可能需要某种任务队列 + 线程池安排,既是为了提高性能,又是为了避免线程过多而导致彼此挨饿。
  • @Marcin:很好,当它表明线程方法可行时,我将实现这样的基础架构
  • 很遗憾您还没有任何答案。
  • 可能是一个糟糕的标题或措辞?有什么改进的想法吗?
  • 您可能会添加一些 wsgi 框架的名称,可能会有一个更面向任务的标题(例如“生成线程以在 WSGI Web 应用程序中创建延迟调用”)。

标签: python django multithreading wsgi flask


【解决方案1】:

WSGI 不指定应用程序进程的生命周期(因为 WSGI 应用程序是 Python 可调用对象)。您可以以完全独立于 Web 服务器的方式运行它,在这种情况下,只有您可以控制生命周期。

WSGI 中也没有任何内容可以禁止您生成线程、进程或做任何您想做的事。

【讨论】:

    【解决方案2】:

    FWIW,也请阅读:

    http://code.google.com/p/modwsgi/wiki/RegisteringCleanupCode

    在 WSGI 规范本身的上下文中,将操作与可迭代的 close() 挂钩是执行延迟工作的唯一方法。虽然这不在单独的线程中,并且会在实际请求的上下文中发生,尽管应该在响应被刷新回客户端之后。因此,您的延迟操作将消耗该请求线程,直到工作完成,因此该请求线程在此之前将无法处理其他请求。

    一般来说,如果您确实使用后台线程,则无法保证任何托管机制都会等到这些后台线程完成后再关闭进程。事实上,甚至想不出任何等待的标准部署机制。甚至不能保证在进程关闭时会调用 atexit 处理程序,参考文档也简要介绍了这一点。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2015-06-25
      相关资源
      最近更新 更多