問題タブ [gil]

Pythonインタープリターから完全に独立した何かを行うC拡張関数があるとしましょう。GILをリリースしない理由はありますか？

たとえば、このようなコードを書かない理由はありますか（読みやすさやマイクロ最適化の回避などの問題は別として、重要ですが、私の質問にはあまり関係ありません）？

明らかに、これはパフォーマンスがそれほど重要ではない些細なコードです。しかし、ここでGILをリリースしないパフォーマンス上の理由はありますか？または、GILは、CPUを集中的に使用するコードに対してのみリリースする必要がありますか？

マルチスレッドを並行して実行する方法があれば教えてください。私が今まで知っていることは、Ruby にはグローバル インタープリター ロックまたはグローバル VM ロックがあり、スレッドが並列に実行され、同時に実装されるのをブロックするということです。スレッドが並列または並行して動作していることを実際に理解し、検証するための詳細なスレッドの例をいくつか教えてください。

このサンプルコードがあるとしましょう：

スレッドを使用して、このコードの実行時間を改善したいと考えています (役に立てば幸いです)。物事をできるだけシンプルにしたいので、基本的にやりたいことは、同時に と を計算する 2 つのスレッドを作成することfoo1ですfoo2。

スレッドについて何か読んでいますが、少しトリッキーで、そのような単純なことをするためだけに時間を無駄にすることはできません。

boost::python とコールバック駆動の実行を含むプロジェクトで問題が発生しています。

私のプロジェクトでは、C++ から Python コードを実行するためにコールバック メカニズムを使用しています。

コールバックの実行を引き起こす最初の関数呼び出しが Python インタープリターからのものである限り、すべて問題ありません。例えば：

残念ながら、それはそれほど単純ではありません。私のプロジェクトはRtAudioを使用してオーディオ環境と通信します。RtAudio の実行はコールバック駆動型です。RtAudio にコールバック関数を渡します。RtAudio を開始すると、サウンドの計算が必要になるたびにコールバックが呼び出されます。

RtAudio のコールバック駆動型実行を使用すると、コードが C++ から Python コールバックを実行しようとするとすぐにセグメンテーション違反が発生します。

コールバック駆動型の実行を開始するには、ノンブロッキングの関数 start() を呼び出す必要があります。これは、コールバック駆動の実行が別のスレッドで発生することを意味します。

次に、python から start() を呼び出すときに、python の実行環境に個別にアクセスする別のスレッドを作成しています。python の GIL を少ししか理解していないため、これは良くありません。

では、このコールバック駆動型スレッドで、すべてを分割せずに Python コールバックを実行するにはどうすればよいでしょうか?

申し訳ありませんが、私の問題の短い、完全に機能する例にコードを単純化する方法を見つけることができませんでした.問題はそこにあります.

編集

Python のドキュメントを調べた後、 Python以外で作成されたスレッドが Python 環境にアクセスしようとしたときに、スレッド セーフを処理するコードを数行追加しました。

しかし、私はまだセグメンテーション違反を起こします。だから私はvalgrindを通してそれを実行しました、そしてここに私が得たものがあります（valgrindが常にpythonインタープリターから取得する奇妙なものを差し引いたもので、これは「通常」です）：

うまくいけば、コールバック関数は NULL ポインタにアクセスしようとしていますか?

編集2

わかりました、私はこれらすべてを発見しています。pthread のドキュメントから、セマフォsem_post(sem)をsem指す への呼び出しがあるようです。しかし、そこでは NULL を指しています。

さて、どうすればエラーをより正確に特定できますか?

私たちは皆、 GILの恐ろしさを認識しており、モジュールを使用する適切な時期について多くの議論を見てきましたがmultiprocessing、Python でスレッド化するとき (フォーカス主に CPython で) が正しい答えです。

GIL が重大なボトルネックにならない例は何ですか? スレッド化が最も適切な答えであるユースケースのタイプは何ですか?

pthreads と HDF5 を使用する Python 用の C++ モジュールを作成しています。私のモジュールは H5F_ACC_EXCL モードで HDF5 ファイルを作成するため、ファイルが既に存在する場合は失敗します。この場合、HDF5 はスタック トレースを出力します。このモジュールの Python C インターフェイス関数は 1 つのスレッドで実行され、ファイルの作成は別のスレッドで行われます。通常はすべて正常に動作しますが、モジュールを使用してスクリプトに h5py をインポートすると、システムがデッドロック状態になります。ファイルを作成しようとするスレッドには、次のバックトレースがあります。

[行 #7 は、モジュール内の関数について通知します] PyTables をインポートしても、この問題は発生しないことがわかりました。この問題を解決するための助けをいただければ幸いです。

なぜmath.factorialはスレッドでそれほど奇妙に動作するのですか？

次に例を示します。3つのスレッドを作成します。

• しばらく眠るだけのスレッド
• しばらくの間intをインクリメントするスレッド
• 多数でmath.factorialを実行するスレッド。

startスレッドを呼び出しjoin、タイムアウトします

startスリープスレッドとスピンスレッドは期待どおりに機能し、すぐに戻ってからjoin、タイムアウトのために待機します。

一方、階乗スレッドはstart、最後まで実行されるまで戻りません。

そして、CentOSx64でのPython2.6.5の出力は次のとおりです。

CentOSx64のpython2.6.5、Windows x86の2.7.2でこれを試しましたが、スレッドの実行が完了するまで、どちらの場合も階乗スレッドは最初から戻りません。

Windowsx86のPyPy1.8.0でもこれを試しましたが、結果が少し異なります。スタートはすぐに戻りますが、その後、参加はタイムアウトしません！

IronPython 2.7.1も試してみましたが、期待どおりの結果が得られます。

ここにも古い同じ質問がありましたが、答えはスレッドの使用に関するものでした。GILでは大丈夫ではないと思いました。

さまざまなポートとさまざまなプロセスで実行されるさまざまなHTTPサーバー（Pythonでさえも）を作成したいと思います。そして、いくつかのパラメーター（HTTP_HOSTなど）を使用して、ポート80からそれらに要求をルーティングしたいと思います。

サーバー側（ルーター内）でHTTPクライアントを使用してポートへの要求を行う必要がありますか、それとも別の方法がありますか？

nginxのようなことをしたいのですが、動的に変更したいのです。

私はマルチスレッドCアプリケーションにPythonインタープリターを埋め込んでいますが、スレッドセーフを確保するためにどのAPIを使用すべきかについて少し混乱しています。

私が収集したものから、Pythonを埋め込む場合、他のPython C API呼び出しを呼び出す前に、GILロックを処理するのは埋め込み者次第です。これは、次の関数で実行されます。

しかし、これだけでは十分ではないようです。Python APIの相互排除を提供していないように見えるため、ランダムにクラッシュすることがあります。

さらにいくつかのドキュメントを読んだ後、私も追加しました：

呼び出しの直後Py_IsInitialized()ですが、それが混乱を招く部分です。ドキュメントには、この関数は次のように記載されています。

グローバルインタプリタロックを初期化して取得する

これは、この関数が戻ったときに、GILがロックされているはずであり、何らかの方法でロックを解除する必要があることを示しています。しかし実際には、これは必須ではないようです。この行を配置すると、マルチスレッドが完全に機能し、PyGILState_Ensure/Release関数によって相互排除が維持されました。に続く呼び出しでアプリがデッドロックした後、すぐに
追加しようとしたとき。PyEval_ReleaseLock()PyEval_ReleaseLock()PyImport_ExecCodeModule()

だから私はここで何が欠けていますか？

私のdjangoアプリは、djangoモデルをリモートデータベースに保存します。保存がバーストする場合があります。アプリケーションのメインスレッド（* thread_A *）を、複数のオブジェクトをデータベースに保存する時間から解放するために、* thread_B *を使用してモデルオブジェクトを別のスレッド（* thread_B *）に転送し、保存することを考えましたcollections.deque。それらを順番に。

しかし、私はこの計画についてはよくわかりません。save()新しいデータベースエントリのIDを返すため、データベースが応答した後、つまりトランザクションの最後にのみ「終了」します。

django.db.models.Model.save()本当にGILをブロックし、トランザクション中に他のPythonスレッドを解放しますか？