マルチスレッドサーバーでの構造化例外処理

Question

この記事では、構造化例外処理が悪い理由。記事で言及されている問題を乗り越えながら、サーバーのクラッシュを防ぐ堅牢性を得る方法はありますか？

約400人の接続ユーザーを同時に実行するサーバーソフトウェアがあります。ただし、クラッシュが発生すると、400人のユーザー全員が影響を受けます。構造化された例外処理を追加し、しばらくの間結果を楽しみましたが、最終的にサーバー全体がハングするクラッシュのために削除する必要がありました（クラッシュして再起動するよりも悪いです）。

これでこれができました：

• SEHを使用すると、ほとんどのクラッシュで問題が発生するのは400人のうち1人だけです
• SEHなし：ユーザーがクラッシュした場合、400人すべてが影響を受けます。
• ただし、SEHの場合：サーバーがハングし、400人すべてが影響を受け、将来接続しようとするユーザーが

Answer 1

プログラムをワーカープロセスと単一のサーバープロセスに分割します。サーバープロセスは、最初の要求を処理してから、ワーカープロセスに渡します。ワーカープロセスがクラッシュすると、そのワーカーのユーザーのみが影響を受けます。一般的な例外処理にSEHを使用しないでください-わかっているように、デッドロックが発生する可能性があります。また、とにかくクラッシュする可能性があります。

Answer 2

プログラムがランダムにクラッシュするためにSEHを使用するのは悪い考えです。プログラムをクラッシュさせないようにプログラムに振りかけることができるのは、魔法の妖精の粉塵ではありません。クラッシュの原因となるバグを追跡して修正することが正しい解決策です。

構造化された例外を本当に処理する必要があるときにSEHを使用するのは問題ありません。 Larry Ostermanは、 SEHが必要な状況：メモリマップファイル、RPC、セキュリティ境界の遷移。

Answer 3

プログラムのバグを修正しますか？ ;）

個人的には、SEHハンドラーを保持し、アクセス違反などが発生した場所の呼び出しスタックをダンプして、問題を修正します。 「サーバーがハングすることがある」問題は、おそらく、何かをロックしたままにするSEH例外を持つスレッドが原因で発生するデッドロックが原因であり、SEH自体を使用しているという事実とは関係ありません。