多くの独立したスレッドを持つアプリを書いています。私は非常に低レベルで危険な作業を行っていますが、スレッドは失敗する可能性があります (SIGSEGV、SIGBUS、SIGFPE) が、プロセス全体を強制終了するべきではありません。適切な方法でそれを行う方法はありますか？
現在、前述のシグナルをインターセプトし、シグナルハンドラーで pthread_exit(NULL) を呼び出します。うまくいくようですが、pthread_exit は async-signal-safe 関数ではないため、この解決策について少し心配しています。
このアプリを複数のプロセスに分割すると問題が解決することはわかっていますが、この場合、実行可能なオプションではありません。
編集: SIGSEGV/SIGBUS/SIGFPE を無視したために起こりうるすべての悪いこと™ を認識しています (私は低レベルのシステムおよびカーネル プログラミングの経験があります)。信頼性についての教訓。
低レイテンシのコード設計には、「実行するシステムに注意する」タイプのコーディングと展開が慎重に行われます。つまり、たとえば、標準のIPC メカニズム (SysV を使用してmsgsnd/msggetプロセス間でメッセージを渡す、またはpthread_cond_wait/ pthread_cond_signalPThreads 側で) と同様に、通常のロック プリミティブ (適応ミューテックス) はかなり遅いと見なされることを意味します ...何千もの CPU サイクルを必要とするもの、つまりコンテキスト スイッチが含まれます。
代わりに、ディスラプター パターンなどの「ホット-ホット」ハンドオフ メカニズムを使用します。プロデューサーとコンシューマーの両方がタイトなループでスピンし、単一または最悪の場合、次のアイテムの場所を示すアトミックに更新された少数のメモリ ロケーションを永続的にポーリングします。 -be-processed が見つかった、および/または処理された項目を完了としてマークします。すべてのプロデューサー/コンシューマーを個別の CPU コアにバインドして、コンテキスト スイッチが発生しないようにします。
このタイプのユースケースでは、個別のスレッドを使用する (そして、すべてのスレッドが同じアドレス空間を共有することによってメモリ共有を暗黙的に取得する) か、個別のプロセスを使用する (そして、データになるデータに共有メモリを使用することによって明示的にメモリを共有する)。 -processed と queue mgmt "metadata") の違いはほとんどありません。TLB とデータ キャッシュは "常にホット" であるためです (コンテキスト スイッチは決してありません)。
「プロセッサ」が不安定であったり、完了時間が保証されていない場合は、失敗したメッセージやタイムアウトしたメッセージを処理するために「リーパー」メカニズムを追加する必要がありますが、そのようなガベージ コレクション メカニズムは必然的にジッター (レイテンシ スパイク) をもたらします。これは、特定のスレッドまたはプロセスが終了したかどうかを判断するためにシステム コールが必要であり、システム コールのレイテンシが最良の場合でも数マイクロ秒であるためです。
私の見解では、あなたはここで油と水を混ぜようとしています。低レイテンシの展開で使用するために特別に作成されていないライブラリ コード/制御できないライブラリ コードを、ナノ秒のレイテンシでメッセージをディスパッチする要件と組み合わせて使用する必要があります。ターゲットをウェイクアップするためにシステムコールを実行する必要があり、それには時間がかかるため、nsec のレイテンシを与えるなどの方法はありません。pthread_cond_signal()
あなたの「ハンドラーコード」が「リッチ」環境に依存し、大量の「状態」がこれらとメインプログラムの間で共有されている場合...「蒸気駆動の飛行機を壊す必要がある」と言っているように聞こえますサウンドバリア」...
これを行う適切な方法は、プロセス全体を終了させ、別のプロセスを開始することです。これが適切でない理由を説明していませんが、本質的には、さまざまな厄介なコーナーケースに対して完全に安全な唯一の方法です (状況に当てはまる場合と当てはまらない場合があります)。
プロセス全体を任せることを伴わない 100% 安全な方法を私は知りません。(また、この種のエラーから継続する行為だけが「未定義の動作」である場合があることに注意してください。これは、間違いなく転倒するという意味ではなく、問題になる可能性があるということです)。
もちろん、うまくいく巧妙なトリックを誰かが知っている可能性はありますが、100% 保証されている唯一の方法は、プロセス全体を強制終了することだと確信しています。