メインスレッドと追加の (切り離された) プロセスが作成されたアプリケーションがあります。そのプロセスでは、ネットワーク経由でキューからログを送信するネットワーク サーバーを実行しています。
問題は、segfault ハンドラーで何かを実行して、そのログ キューの送信を待機/終了することは可能かということです。したがって、そのキューのほぼ 100% の配信が必要です。
メインスレッドと追加の (切り離された) プロセスが作成されたアプリケーションがあります。そのプロセスでは、ネットワーク経由でキューからログを送信するネットワーク サーバーを実行しています。
問題は、segfault ハンドラーで何かを実行して、そのログ キューの送信を待機/終了することは可能かということです。したがって、そのキューのほぼ 100% の配信が必要です。
プロセスが終了するまで wait() を、スレッドが終了するまで pthread_wait() を使用できます (どちらを使用するかを明確に指定していません)。
segfault ハンドラーを使用している場合、メモリがめちゃくちゃになり (malloc() と free() を避ける)、FILE * も破損する可能性があることに注意してください。
segfault ハンドラーを作成することは可能ですが、私は強くお勧めしません。まず、segfault ハンドラーの segfault が原因で、プログラムを「終了しない」状態にするのは非常に簡単です。
第二に、dan3 が言及しているように、プロセスのメモリが破損した状態にある可能性が高く、何が機能し、機能しないかを判断するのが難しくなります。
最後に、プロセスからのコアダンプを使用して問題を追跡する機会を失います。
推奨されていませんが、可能です。
私が推奨するのは、メモリー割り当てとポインターの使用をできるだけ避ける小さなプログラムを作成することです。おそらく、バッファをグローバル配列として作成し、数人の熟練した開発者がレビューして徹底的にテストできる限定されたコードでのみアクセスします (ここではストレス テストが優れています)。ただし、送信者または受信者がクラッシュした場合、メッセージが失われる可能性があるため、努力する価値がない可能性があることに注意してください.
ところで、Netscape が最初に Linux 用のバージョンのブラウザーを作成したとき、私はそれを実行しましたが、ロックアップ状態になり続けました。プログラムを使用するstrace
と、無限のセグメンテーション違反ループにあることがすぐにわかりました。非常にイライラし、ほぼ 100% の CPU が浪費されます。