다중 스레드 서버를 사용한 구조화 된 예외 처리

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 자체를 사용하고 있다는 사실과 관련이 없을 것입니다.