問題 6721 に関して、Linux の同じ Python アプリケーションでマルチプロセッシングとユーザー スレッドの両方を使用するためのベスト プラクティスまたは回避策は何ですか? Python 標準ライブラリのロックはフォークでサニタイズする必要がありますか?
なぜ両方が必要なのですか？私は子プロセスを使用して大量の計算を行い、データ構造の結果が大きすぎてキューを介して返すことができません。結果はすぐにディスクに格納する必要があります。これらの子プロセスのそれぞれを個別のスレッドで監視することは効率的であるように思われました。これにより、終了時にスレッドが大きな (たとえばマルチ GB) データを読み取る IO をプロセスに戻すことができ、そこで結果がさらに計算するために必要になりました。他の子プロセスの結果と組み合わせます。子プロセスが断続的にハングしますが、これは (頭をドキドキさせた後) ロギング モジュールを使用することによって「原因」であることがわかりました。他の人はここで問題を文書化しています：
https://twiki.cern.ch/twiki/bin/view/Main/PythonLoggingThreadingMultiprocessingIntermixedStudy
これは明らかに未解決の python の問題を示しています。Python 標準ライブラリのロックは fork でサニタイズする必要があります。 http://bugs.python.org/issue6721
これを追跡するのが難しいことに驚いた私は、次のように答えました。
Python で Multiprocessing と Threading モジュールを混在させない理由はありますか
「注意してください」というかなり役に立たない提案と上記へのリンクがあります。
しかし、問題 6721 に関する長い議論は、同じアプリケーションでマルチプロセッシング (または os.fork) とユーザー スレッドの両方を使用するのは「バグ」であることを示唆しています。この問題についての私の理解は限られているため、同じアプリケーションでマルチプロセッシングとスレッド化の両方を使用するための回避策または戦略について結論を出すには、議論に意見の相違が多すぎます。当面の問題はロギングを無効にすることで解決されましたが、親プロセスと子プロセスの両方で少数の他の (明示的な) ロックを作成しており、さらに断続的なデッドロックに備えているのではないかと疑っています。
Python (2.7,3.2,3.3) アプリケーションでスレッド化とマルチプロセッシングを使用しているときに、ロックやログ モジュールを使用しているときにデッドロックを回避するための実用的な推奨事項を教えてください。