c - Erlang NIF とスレッドの問題

Question

Erlang NIF のスレッドに少し問題があります。ここで私のコードを表示できます: http://pastebin.com/HMCj24Jp。問題は、スレッドを開始するときに、いくつかの引数を取り、generate_binary関数を開始することです。これは問題ありませんが、引数を読み取ろうとするとすべてがクラッシュします。

おそらく最も複雑な問題ではありませんが、これに関するドキュメントが見つからなかったので、答えを知っている人がいるといいのですが。

Answer 1

NIFgenerate_buffer()は呼び出すスレッドを作成していますgenerate_binary()が、呼び出し元の NIF は、新しく作成されたスレッドが終了するのを待ちません。スレッドは作成されたばかりで、NIF が返されるまでにまだ実行されている可能性がありますが、スレッドは一般的に非決定論的です。おそらく Erlang BEAM エミュレーターをクラッシュさせているのは、 が戻っgenerate_binary()た後に Erlang ランタイム システムを呼び出そうとしているためです。generate_buffer()

ここで、これを修正して希望どおりに動作させると仮定しても、ここで明示的なネイティブ スレッドを使用する必要はまったくないと思います。

まず、Erlang NIF は通常の Erlang 関数のように見えるはずですが、異なる言語で書かれているという点だけが異なります。Erlang 関数は、個別の実行スレッドを生成してから戻り、そのスレッドを実行したままにすることはありません。I/O と永続的なデータ ストレージを扱うものを除いて、Erlang 関数は決定論的で参照透過的です。あなたのNIFはどちらでもありません。したがって、それが機能したとしても、経験豊富な Erlang プログラマーの期待に反するという意味では、まだ「間違っている」と言えます。

次に、マルチプロセッシングが必要な場合、Erlang はすでにプロセスの概念を提供しています。あなたの NIF が実際にマルチプロセッシングの恩恵を受けることができるほど多くの作業を行うのであれば、NIF を作り直して、データの部分範囲を処理できるようにしてから、多数の Erlang プロセスからそれぞれ 1 回ずつ、複数回呼び出してみませんか? 次に、明示的なネイティブ スレッドは必要ありません。BEAM エミュレーターは、最適な数のスレッドを透過的に作成します。

第三に、実際に意図したように、スレッドの寿命が単一の Erlang NIF 呼び出しの過程でのみ延長される場合、スレッド作成のオーバーヘッドによりパフォーマンスが低下します。これは、ここで Erlang プロセスがより効率的になるもう 1 つの理由です。