2

mruby Rust バインディングのスレッドセーフ バージョンを実装しようとしています。

mruby には*mut MRState(のラッパーmrb_state) があります。*mut MRStatemruby コードを実行するときにこれを渡す必要があります。*mut MRStatemruby コードには、同じ変数を渡す場所で呼び出すことができる Rust コールバックがあります。

これは、スレッドセーフにしようとしている に*mut MRStateラップされています。MRuby struct問題は、 でラップMRubyするMutexと、Rust で作成されたコールバック内に再入力できなくなることです。

私は現在ラップMRubyしてRwLockいますが、あまり役に立ちません。は*mut MRState、コールバック内で実行できるように、より寛容なロックにする必要があります。

MRubyコールバックの両方で機能させ、別のスレッドから呼び出された場合に強制的に待機させるにはどうすればよいですか?

これとは別に、&ではない*mut MRState内部に問題があります。MRubySendSync

struct MRuby {
    mrb: *mut MRState,
    ...
}

これはコールバックの例です。

// this callback will be run with a mrb_ function with takes
// *mut MRState as an argument, so it would need to lock
extern "C" callback(...) {
    // I need to use MRuby here which will make use of
    // its inner *mut MRState
    ...
}

これは、スレッドで mruby を実行する例です。mrubyここの変数はArc<RwLock<MRuby>>.

thread::spawn(move || {
    mruby.run("*mruby code*"); // should run sequentially with
                               // with a lock on *mut MRState
});

これを実装したい主な理由は機能ではありません。実際にcatch_panicは、Rust コールバックから発生する可能性のあるパニックをキャッチするために必要です。別のスレッドで実行されるため、スレッドセーフcatch_panicにする必要があります。MRubyRust は 1.9.0 でのみ安定std::panicします。それまでは、毎晩 Rust を必要としない実用的なソリューションが必要です。

修正

Rust のドキュメンテーション生成のバグにより、catch_panic非推奨としてのみマークされ、不安定ではありません。したがって、非常に簡単な解決策はstd::panic、スレッドセーフを使用して放棄することです。ただし、前述のことを考慮すると、私の個人的な関心は低くなりますが、これに対する良い答えがある場合に備えて、質問を開いたままにします。

4

0 に答える 0