Google App Engineの「遅延呼び出し」と同様の処理（つまり、要求が処理された後に遅延タスクが処理される）を達成するために、少し実験を行い、遅延呼び出しが発生するスレッドを生成するソリューションがありました処理されます。wsgiアプリケーションでスレッドを生成することはできますか？
私は現在これが許容される方法であるかどうかを判断しようとしています。
WSGI仕様によれば、実際の要求が処理された後、すべてのスレッドが使い果たされる前に、Webサーバーによってプロセスが終了する可能性はありますか？
（WSGIアプリケーションはPythonの呼び出し可能オブジェクトであるとして）
FWIW、またの読んだ：反復可能なの
http://code.google.com/p/modwsgi/wiki/RegisteringCleanupCode
（クローズするアクションのフックは）繰延仕事をするためのWSGI仕様自体の文脈の中での唯一の方法です。これは別のスレッドではなく、実際の要求のコンテキスト内で発生しますが、応答がクライアントにフラッシュされたはずです。したがって、延期されたアクションは、作業が完了し、要求スレッドがこれまでに他の要求を処理できなくなるまで、要求スレッドを消費します。
一般に、バックグラウンドスレッドを使用する場合、プロセスをシャットダウンする前にバックグラウンドスレッドが完了するまでホスティングメカニズムが待機する保証はありません。実際には、待っている標準的な展開の仕組みについて考えることさえできません。プロセスシャットダウン時にatexitハンドラが呼び出されるという保証はありません。参照されたドキュメントも簡単に説明しています。
WSGIは、アプリケーションプロセスの有効期間を指定していない（より良い方法がありますならば、それはまた、罰金になります）。 Webサーバーから完全に独立した方法で実行することができます。この場合、ライフタイムのみを制御します。
WSGIには、スレッドやプロセスを生成したり、何か必要なことをすることを禁止するものもありません。
偉大な用語。 –
パフォーマンスのために、またスレッドがお互いに飢えてしまうのを避けるために、何らかのタスクキュー+スレッドプールの配置が必要になるでしょう。 – Marcin
@Marcin：良い点、スレッドのアプローチが実現可能であることを示すとき、私はそのようなインフラストラクチャを実装します – keppla
あなたはまだ答えがありませんでした。 – Marcin