UnwindSafeオートトレイトの可変参照に対する保守的なオプトアウトセマンティクスの背後にあるアーキテクチャの根拠を評価し、catch_unwindと内部可変性を組み合わせる際に例外安全性違反を防ぐ方法を説明してください。

質問への回答

質問の歴史

UnwindSafeトレイトは、Rust 1.9でstd::panic::catch_unwindと共に導入され、C++やその他の例外処理を持つ言語から引き継がれる例外安全性の懸念に対処しています。Rustでは、パニックがスタックのアンワインディングを引き起こし、Drop実装が実行されることが保証されますが、これはパニックが論理的操作を中断した場合にデータ構造が一貫した状態のままであることを自動的に保証するものではありません。このトレイトは、catch_unwindの境界を跨いでアクティブな状態に耐えることができる型をマークするために設計されており、未定義の動作や論理エラーのリスクを冒すことがありません。

問題

可変参照（&mut T）がcatch_unwindの境界を跨ぐときに、Tが内部可変性（RefCellやCellなど）を含んでいる場合、パニックはTを論理的に一貫性のない状態に残す可能性があります。例えば、RefCell::borrow_mutと結果として得られるRefMutガードの暗黙のドロップの間でパニックが発生した場合、RefCellの内部借用カウントは増加したままになります。catch_unwindがパニックをキャッチし、実行が再開されると、RefCellは可変的に借用されているように見えますが、カウントを減少させるためのガードはアンワインド中にドロップされています。この「汚染された」状態は例外安全性の違反を構成しており、RefCellに対するその後の操作はパニックを引き起こすか、誤った動作をする可能性があり、安全なコードが検出またはリカバリできない形でプログラムの状態を腐敗させてしまいます。

解決策

UnwindSafeは保守的なマーカートレイトとして機能します：これはほとんどの型に自動的に実装されますが、&mut Tおよびそれを含む任意の集約型に対しては明示的にオプトアウトされています。型システムが**&mut TのUnwindSafe実装を禁止することにより、プログラマーがAssertUnwindSafeで明示的にラップしない限り、可変参照がcatch_unwind**に渡されることを防ぎます。このラッパーは、プログラマーがラップされた型が内部可変性を持たないか、例外安全性を手動で確認したことを主張する安全な契約です。このアーキテクチャの選択により、パニック境界を越える可変で内部可変な状態を偶然に露出させるリスクはコンパイル時にキャッチされるようになります。

use std::panic::{catch_unwind, AssertUnwindSafe};
use std::cell::RefCell;

fn main() {
    let shared = RefCell::new(vec![1, 2, 3]);
    
    // これはコンパイルに失敗します。なぜなら&mut RefCellはUnwindSafeではないからです:
    // let _ = catch_unwind(|| {
    //     let mut borrow = shared.borrow_mut();
    //     borrow.push(4);
    //     panic!("interrupted");
    // });
    
    // unsafeな認識での明示的なオプトイン:
    let result = catch_unwind(AssertUnwindSafe(|| {
        let mut borrow = shared.borrow_mut();
        borrow.push(4);
        panic!("interrupted");
    }));
    
    // パニックの後、sharedは無効な借用状態にあるかもしれませんが、
    // 我々はこのリスクをAssertUnwindSafeで明示的に認めていました。
    println!("Recovered: {:?}", result.is_err());
}

実生活の状況

問題の説明

hyperを使用して構築された高性能のHTTPサーバーは、ユーザー定義のリクエストハンドラ内のパニックを隔離する必要があります。これにより、不正なリクエストが全プロセスを終了させるのを防ぎます。サーバーは、各スレッドのアクティブなデータベース接続を追跡するためにRefCellを使用して接続プールを維持しています。このアーキテクチャは、各リクエストハンドラをcatch_unwindでラップし、パニックをキャッチして優雅にログを取ります。負荷テスト中、サーバーは接続プールのRefCellの可変借用を保持しているハンドラ内でパニックに遭遇します。catch_unwindがパニックをキャッチすると、プールの内部借用フラグは"可変借用中"に設定されたままになります。なぜなら、RefMutガードは、その減少ロジックを実行せずにアンワインディング中にドロップされたからです。同じスレッド上の後続リクエストはプールを借りようとし、その時点で既に借用された状態が原因で実行時パニックを引き起こし、スレッドはクラッシュし、プールの状態を失います。

解決策1: catch_unwindを排除し、プロセス終了を許可する

このアプローチは、プロセスが任意のパニックでクラッシュすることを許可することによって、例外安全性の問題を完全に排除します。この特定の文脈では、可用性が正確性に対して二次的であることを受け入れるのです。

利点: 例外安全性の懸念を完全に排除する; 状態の腐敗のリスクなし; 実装が簡単。

欠点: 生産環境での可用性には受け入れがたい; 悪意あるリクエストやバグのあるリクエスト1つで、全サービスが終了する; 信頼性の要件に違反する。

解決策2: RefCellをMutexに置き換え、浸食を利用する

RefCellベースのプールを**Mutex<Pool>**に置き換え、Rustのミューテックス浸食検出を利用します。

利点: Mutexは、保持スレッド内のパニックを検出し、自己を汚染マークし、後続のロック試行がPoisonErrorを通じて腐敗を検出できるようにします; 標準ライブラリが組み込みの安全性を提供します。

欠点: Mutexは、単一スレッドの非同期実行者に対して不要な同期オーバーヘッドを導入します; 接続プールがSendである必要があり、構造の再構成が必要です; 浸食はプールを再初期化するための明示的な処理ロジックを必要とします。

解決策3: ハンドラをAssertUnwindSafeでラップし、状態検証を行う

性能のためにRefCellを保持しますが、ハンドラをAssertUnwindSafeでラップし、パニックが発生した場合にRefCellの状態をリセットするカスタムドロップガードを実装します。

利点: RefCellの性能メリットを保持; パニック隔離を可能にする; リカバリロジックを実装可能。

欠点: AssertUnwindSafeとの相互作用でunsafeコードが必要; すべてのコードパスに対する例外安全性を保証するのが非常に難しい; 状態が腐敗したまま残るエッジケースを見逃しやすい。

選択された解決策とその理由

チームは共有接続プールに対して解決策2（浸食付きミューテックス）を選択し、リクエスト特有の一時バッファについては再初期化が容易な解決策3のみを使用しました。Mutexの明示的な浸食メカニズムは、すべての可能なパニックポイントのunsafe監査を必要とせずに、腐敗を検出するための信頼性のある標準化された方法を提供します。安全保障のために小さなパフォーマンスオーバーヘッドが受け入れられました。

結果

サーバーはリクエストハンドラ内のパニックを隔離し、状態の腐敗をリスクにさらさずに成功しました。ハンドラがプールロックを保持している間にパニックが発生すると、ミューテックスは汚染され、サーバーは次回のアクセス時にこれを検出し、腐敗したスレッドローカルプールを破棄して新しいプールを生成します。これにより、未定義の動作が生じることなく、サービスは不正な入力の下でも可用性を保ちます。

候補者がしばしば見落とすこと

なぜcatch_unwindはUnwindSafeを要求するのか、Rustはパニック中にデストラクタを実行するのに？

多くの候補者は、Drop実装がアンワインディング中に実行されるため、例外安全性が保証されていると考えています。しかし、UnwindSafeはデータの論理状態に対処しており、リソースリークだけではありません。パニックは、オブジェクトが一時的に不一致の状態にあるまま、操作のシーケンス（例えば、対応するデータの前に長さフィールドを更新する）の更新を中断することがあります。デストラクタはこの壊れた状態で実行され、腐敗を伝播する可能性があります。UnwindSafeは、型が中断によって壊れないか、プログラマーがリスクを認識していることを保証します。それによって、自分自身の不変条件を違反するオブジェクトでの実行の再開を防ぎます。

UnwindSafeとSend/Syncオートトレイトの違いは何ですか？

SendおよびSyncもオートトレイトですが、ポジティブな推論を使用します：&TがSendであるのはTがSyncである場合、&mut TがSendであるのはTがSendである場合です。UnwindSafeはネガティブな推論を使用します：&mut Tは決して UnwindSafeではなく、Tに関係なく。さらに、AssertUnwindSafeは特定の値に対するエスケープハッチとして機能し、型レベルでのunsafe implとは異なります。UnwindSafeは、共有参照のためにRefUnwindSafeとペアになり、Send/Syncとは異なる二重トレイトシステムを作成します。

RefCellの借用フラグがパニック時にどのように安全性を損なうか、そしてなぜMutexは同様のUnwindSafe問題を持たないのか？

RefCellはランタイム借用フラグに依存しています。borrow_mut()とガードのDropの間にパニックが発生した場合、フラグは設定されたままになりますが、ガードは消えます。実行が再開されると、RefCellは借用されているように見えますが、実際には借用は存在しません。これは論理エラーであり、将来の借用が誤ってパニックを引き起こす原因となります。Mutexは、ロックが保持されている間にパニックが発生した場合に自己を汚染されるようにマークすることでこの問題を回避します。そのため、次回のlock()呼び出しは、以前のスレッドがパニックしたことを示すエラーを返します。これにより、腐敗が明示的かつ検出可能になりますが、RefCellの腐敗は静かに発生します。したがって、MutexGuardは実際には!UnwindSafeですが、浸食メカニズムはRefCellが欠く安全な回復パスを提供します。