使用多線程服務器進行結構化異常處理

Question

This article很好地概述了爲什麼結構化異常處理不好。有沒有辦法獲得停止服務器崩潰的穩健性，同時克服文章中提到的問題？

我有一個同時運行約400個連接用戶的服務器軟件。但是如果出現故障，所有400個用戶都會受到影響。我們添加了結構化的異常處理，並享受了一段時間的結果，但最終不得不刪除它，因爲一些崩潰導致整個服務器掛起（這比只讓它崩潰並重新啓動本身更糟糕）。

所以我們有這樣的：

• 隨着SEH：只有1個用戶在400得到一個問題，最崩潰
• 沒有SEH：如果任何用戶獲取崩潰，所有的400都受到影響。
• 但是有時SEH：服務器掛起，所有400都受到影響，並且未來的用戶嘗試連接。

Answer 1

將程序分解爲工作進程和單個服務器進程。服務器進程將處理初始請求，然後將其從工作進程中移出。如果工作進程崩潰，則只有該工作的用戶受到影響。不要使用SEH進行一般的異常處理 - 正如你所發現的那樣，它可以並且會讓你面臨死鎖，並且仍然可以崩潰。

Answer 2

使用SEH是因爲你的程序隨機崩潰是一個壞主意。這不是魔法小精靈，你可以把它灑在程序上，讓它停止崩潰。跟蹤並修復導致崩潰的錯誤是正確的解決方案。

當你真的需要處理結構化異常時使用SEH很好。拉里奧斯特曼做了一個後續解釋what situations require SEH: memory mapped files, RPC, and security boundary transitions。

Answer 3

修復程序中的錯誤？ ;）

就我個人而言，我會保留SEH處理程序，讓他們傾倒出訪問衝突或發生的任何事情的調用堆棧並解決問題。 '有時服務器掛起'的問題可能是由於SEH異常保持鎖定的線程造成的死鎖，所以不太可能與您使用SEH本身有關。