我通常不需要在我的Django应用程序级编程（即视图）中显式使用线程。但我注意到一个看起来很有趣的库，通过线程处理服务器端分析。
在Django视图中，您将使用他们的Python客户端在单独的（非守护程序）线程中将HTTP POST批量处理到其Web服务。通常情况下，我会选择使用RabbitMQ来代替线程，但是他们希望降低库的启动成本。
我的问题是，这种方法有什么缺点吗？线程有一些额外的内存占用，但我并不太担心。它显然取决于启动的请求/线程数。
线程是不是守护进程并且可能长期存在问题？我假设Gunicorn进程是执行的主线程并且它在无限循环中运行，因此通常无论是否必须等待非守护进程线程退出。这是对的吗？
这是一个悬而未决的问题，但重点是了解Django / Gunicorn应用程序中非守护程序线程的影响。
答案 0 :(得分：6)
Gunicorn使用前叉工人模型。主进程生成并管理工作进程。对于非Tornado用途，有两种工人：Sync（默认）和Async。
在正常操作中，这些Worker会循环运行，直到Master告诉他们正常关闭或杀死它们。工人将定期向主人发出心跳，表明他们仍然活着并且正在工作。如果发生心跳timeout，那么主人将杀死工人并重新启动它。
因此，不干扰Worker主循环的守护进程和非守护进程线程应该没有影响。如果线程确实干扰了Worker的主循环，例如线程正在执行工作并将向HTTP响应提供结果的场景，那么请考虑使用异步工作器。异步工作者允许TCP连接长时间保持活动状态，同时仍允许工作者向主服务器发出心跳。