問題タブ [erlang-nif]

nif関数（erlang nif）内でprotobufを使用しており、protobufメッセージタイプのリソースを作成する必要があります。私はこのようなものを書きました：

問題は..protobufメッセージをこのようにコピーし、クリーンアップ時に次のようにリリースすることは合法ですか？

？すべてがここにあるようですが、私は確信が持てません。コピーされたオブジェクトのコンストラクターが呼び出されず、静的変数などの魔法がある可能性があります...また..memcpyの後にCopyFromを呼び出す必要がありますか？

upd：MyClassはCではなくC++クラスです

1 つの Erlang プロセスでのみ使用される Erlang C NIF を作成しています。ポインターの配列を保持する構造体を作成したいと考えています。これは、プロセスの NIF 呼び出しの間に存在する必要があります。

私が洞察を必要としているのは、Erlang NIF 側からこのアプローチを行う適切な方法です。すべての関数の外側に構造体を記述して、すべての人がアクセスできるようにすることを考えています。NIF への 1 回の呼び出しで作成し、戻って NIF への別の呼び出しで使用すると、問題なく動作するようです。

これは、プロセスがスケジューリング スレッドに対してローカルにとどまっているため、メモリ内の構造体と基になる配列を移動する必要がないためではないかと心配しています。

関数内から erlang:memalloc を使用し、グローバルをすべて一緒に回避するべきですか、それともグローバル構造体をそのまま使用するべきですか?

すべてのデータを含む単一の配列へのポインターを返す可能性がありますか?

Erlang C NIFを作成する場合、Cで作成されたポインター（たとえば配列）をErlangに返して、後で別のNIF呼び出しで同じErlangプロセスで使用できるようにするにはどうすればよいですか？

同じErlangプロセス内からNIFに戻ったときに、ポインターとそれが参照するメモリーにアクセスできるように、ポインターを返すか、保存することもできます。

なぜ使用するのか

とは対照的に

Erlang C NIF からメモリを割り当てようとするとき?

参考文献では、その理由についてあまり特定されていません。

http://www.erlang.org/doc/man/erl_nif.html#enif_alloc

mallocアーランに、の代わりにC NIFドロップインがあるのに、なぜenif_allocないのcallocですか？これにより、配列アクセスのmemset()後に使用するように強制されます。enif_alloc

自分でescriptを記述すれば、nifを使用できますが、rebar escriptizeを使用すると、nif関数が見つかりません。*.soオブジェクトがビームファイルのようにパックされていないためだと思います。これは簡単な例です。

rebar.config：

test.erl：

rebar get-deps compile
escriptize ./test

結果は

これを克服する方法はありますか？

Erlang VM ビームが C で記述されたコードを実行すると、Erlang で記述された他のプロセスがスケジュールされませんでした。例えば：

この C 関数を Erlang で呼び出すと、他のプロセスが正常にスケジューリングされませんでした。なぜ知りたいのですか？これは機能ですか、それとも実装によって制限されていますか (つまり、これはバグですか)?

上記のコードのアドレスはhttps://github.com/davisp/sleepyにあります。