UnwindSafe 자동 특성의 수정 가능한 참조에 대한 보수적인 선택 해제 의미의 건축적 이유를 평가하고, catch_unwind와 내부 가변성을 결합할 때 이것이 예외 안전 위반을 어떻게 방지하는지 설명하시오.

질문에 대한 답변.

질문의 역사

UnwindSafe 특성은 Rust 1.9에서 std::panic::catch_unwind와 함께 도입되어 C++ 및 기타 예외 처리를 지원하는 언어에서 물려받은 예외 안전 문제를 해결했습니다. Rust에서 패닉은 스택 언와인딩을 트리거하여 Drop 구현이 실행되도록 보장하지만, 패닉이 논리적 작업을 중단할 경우 데이터 구조가 일관된 상태를 유지하는 것을 자동으로 보장하지는 않습니다. 이 특성은 catch_unwind 경계를 넘어 활성 상태에 있는 것을 허용하면서 정의되지 않은 동작이나 논리 오류의 위험을 최소화하는 타입을 표시하기 위해 설계되었습니다.

문제

수정 가능한 참조(&mut T)가 catch_unwind 경계를 넘어갈 때, T가 내부 가변성(예: RefCell 또는 Cell)을 포함하면, 패닉이 발생하여 T를 논리적으로 일관되지 않은 상태로 남겨둘 수 있습니다. 예를 들어, 패닉이 RefCell::borrow_mut와 결과적인 RefMut 가드의 암묵적 드롭 사이에서 발생하면, RefCell의 내부 대여 카운트는 증가한 상태로 유지됩니다. catch_unwind가 패닉을 포착하고 실행이 재개되면, RefCell이 수정 가능하게 대여된 것으로 보이지만, 카운트를 감소시키는 가드는 언와인딩 중에 드롭되었습니다. 이 "오염된" 상태는 예외 안전 위반을 구성하며, 이후 RefCell에 대한 작업이 패닉을 일으키거나 잘못된 동작을 하여 안전한 코드가 이를 감지하거나 복구할 수 없게 만듭니다.

해결책

UnwindSafe는 보수적인 마커 특성으로 작동합니다: 대부분의 타입에 대해 자동으로 구현되지만 &mut T 및 이를 포함하는 모든 집합체에 대해서는 명시적으로 선택 해제됩니다. &mut T가 UnwindSafe를 구현하는 것을 금지함으로써 타입 시스템은 프로그래머가 명시적으로 AssertUnwindSafe로 감싸지 않는 한, catch_unwind로 수정 가능한 참조를 전달하는 것을 방지합니다. 이 래퍼는 프로그래머가 포장된 타입이 내부 가변성이 없거나 예외 안전성을 수동으로 확인했음을 주장하는 안전하지 않은 계약입니다. 이 아키텍처 선택은 패닉 경계를 넘어 수정 가능한 내부 가변 상태의 우연한 노출이 컴파일 타임에 파악되도록 보장합니다.

use std::panic::{catch_unwind, AssertUnwindSafe};
use std::cell::RefCell;

fn main() {
    let shared = RefCell::new(vec![1, 2, 3]);
    
    // &mut RefCell이 UnwindSafe가 아니므로 컴파일이 실패합니다:
    // let _ = catch_unwind(|| {
    //     let mut borrow = shared.borrow_mut();
    //     borrow.push(4);
    //     panic!("중단됨");
    // });
    
    // 위험을 명시적으로 인정한 선택적 선택:
    let result = catch_unwind(AssertUnwindSafe(|| {
        let mut borrow = shared.borrow_mut();
        borrow.push(4);
        panic!("중단됨");
    }));
    
    // 패닉 이후, shared는 유효하지 않은 대여 상태에 있을 수 있지만,
    // 우리는 AssertUnwindSafe를 사용해 이 위험을 명시적으로 인정했습니다.
    println!("복구됨: {:?}", result.is_err());
}

실제 상황

문제 설명

hyper로 구축된 고성능 HTTP 서버는 사용자 정의 요청 핸들러에서 발생하는 패닉을 격리하여 잘못된 요청 하나가 전체 프로세스를 종료하지 않도록 해야 합니다. 이 서버는 각 스레드당 활성 데이터베이스 연결을 추적하기 위해 RefCell을 사용하는 연결 풀을 유지합니다. 아키텍처는 각 요청 핸들러를 catch_unwind로 감싸며 패닉을 포착하고 우아하게 기록합니다. 부하 테스트 중 서버는 연결 풀의 RefCell을 수정 가능하게 대여하는 핸들러에서 패닉을 만납니다. catch_unwind가 패닉을 캡처할 때, 풀의 내부 대여 플래그는 "수정 가능하게 대여됨"으로 설정된 상태가 유지됩니다. 이후 동일한 스레드의 요청이 풀을 대여하려고 할 때, 이미 대여된 상태 때문에 런타임에서 패닉이 발생해 스레드가 종료되고 풀 상태를 잃게 됩니다.

해결책 1: catch_unwind 제거 및 프로세스 종료 허용

이 방법은 패닉 발생 시 프로세스를 종료하도록 하여 예외 안전 문제를 완전히 제거합니다. 특정 맥락에서 가용성이 정확성보다 주차임을 수용합니다.

장점: 예외 안전 문제를 완전히 제거; 상태 손상 위험 없음; 구현이 간단함.

단점: 생산 가용성에 대해 받아들일 수 없음; 악의적이거나 버그가 있는 요청 하나가 전체 서비스를 종료시킴; 신뢰성 요구 사항 위반.

해결책 2: RefCell을 Mutex로 교체하고 오염 활용

RefCell 기반 풀을 **Mutex<Pool>**으로 교체하고 Rust의 뮤텍스 오염 감지를 활용합니다.

장점: Mutex는 지닌 스레드에서 패닉을 감지하고 자신을 오염으로 표시하여, 이후 잠금 시도에서 PoisonError를 통해 손상을 감지합니다; 표준 라이브러리는 내장된 안전성을 제공합니다.

단점: Mutex는 단일 스레드 비동기 실행기에 불필요한 동기화 오버헤드를 도입합니다; 연결 풀 재구성을 위해 Send가 필요합니다; 오염을 감지하기 위한 명시적 처리 로직이 필요합니다.

해결책 3: AssertUnwindSafe로 핸들러를 감싸고 상태 검증

성능을 위해 RefCell을 유지하지만 핸들러를 AssertUnwindSafe로 감싸고 패닉 발생 시 RefCell 상태를 재설정하는 사용자 정의 드롭 가드를 구현합니다.

장점: RefCell의 성능 이점을 유지하고; 패닉 격리 허용; 복구 로직 구현 가능.

단점: AssertUnwindSafe와 상호작용하는 unsafe 코드를 요구합니다; 모든 코드 경로에 대해 예외 안전성을 보장하기 매우 어렵고, 상태가 손상되는 경계 사례를 놓치기 쉽습니다.

선택된 해결책과 이유

팀은 공유 연결 풀에 대해 해결책 2(오염이 있는 Mutex)를 선택하고, 요청별 일시적 버퍼에 대해서만 쉽게 재초기화할 수 있는 해결책 3을 사용했습니다. Mutex의 명시적 오염 메커니즘은 모든 가능한 패닉 지점에 대해 unsafe 감사가 필요 없이 손상을 감지하는 신뢰할 수 있는 표준화된 방법을 제공합니다. 안전 보장을 위해 소소한 성능 오버헤드는 수용되었습니다.

결과

서버는 상태 손상의 위험 없이 요청 핸들러에서 패닉을 성공적으로 격리합니다. 핸들러가 풀 잠금을 보유하면서 패닉이 발생하면, 뮤텍스가 오염되고 서버는 다음 접근 시 이를 감지하여 손상된 스레드 로컬 풀을 폐기하고 새로운 풀을 생성합니다. 이로써 정의되지 않은 동작이 발생하지 않으며, 악의적인 입력에도 서비스가 계속 제공될 수 있습니다.

후보자들이 자주 놓치는 것

왜 catch_unwind에는 UnwindSafe가 필요한가? 패닉 중에 Rust가 소멸자를 실행하는데도 말입니다.

많은 후보자들은 Drop 구현이 언와인딩 중에 실행되기 때문에 예외 안전성이 보장된다고 가정합니다. 그러나 UnwindSafe는 데이터의 논리적 상태를 다루는 것이지 리소스 누수에 대한 것만이 아닙니다. 패닉이 작업 시퀀스를 중단할 수 있으며(예: 데이터에 따라 길이 필드를 업데이트하려고 할 때), 객체가 임시로 일관되지 않은 상태에 남겨질 수 있습니다. 소멸자는 이 깨진 상태에서 실행될 수 있으며, 잠재적으로 손상을 전파할 수 있습니다. UnwindSafe는 타입이 중단에 의해 깨질 수 없거나 프로그래머가 위험을 인정하도록 강제합니다. 이는 자신의 불변성을 위반하는 객체로 실행을 재개하는 것을 방지합니다.

UnwindSafe와 Send/Sync 자동 특성의 차이는 무엇인가요?

Send와 Sync 또한 자동 특성이지만, 긍정적인 추론을 사용합니다: &T가 Send이면 T는 Sync 이고, &mut T가 Send이면 T가 Send입니다. 반면, UnwindSafe는 부정적인 추론을 사용합니다: &mut T는 절대 UnwindSafe가 아닙니다, T에 관계없이. 또한 AssertUnwindSafe는 값 수준의 탈출 해치 역할을 하며(특정 값에 대한 unsafe impl과 유사하지만), Send/Sync 위반은 일반적으로 타입 수준에서 unsafe impl을 요구합니다. UnwindSafe는 공유 참조에 대해 RefUnwindSafe와 짝을 이루어, Send/Sync와 유사하지만 구별되는 이중 특성 시스템을 만듭니다.

RefCell의 대여 플래그가 패닉과 함께 어떻게 안전성 문제를 일으키며, Mutex는 왜 동일한 UnwindSafe 문제를 가지지 않을까요?

RefCell은 런타임 대여 플래그에 의존합니다. **borrow_mut()**와 가드의 Drop 사이에 패닉이 발생하면, 플래그는 설정된 상태로 남아 있지만, 가드는 사라집니다. 실행이 재개되면, RefCell은 대여된 것으로 보이지만 실제로는 대여가 존재하지 않습니다. 이는 논리적 오류로 인해 이후 대여가 잘못된 방식으로 패닉을 유발합니다. Mutex는 오염을 구현함으로써 이를 피합니다: 잠금을 보유하고 있는 동안 패닉이 발생하면, Mutex는 자신을 오염으로 표시합니다. 이후 lock() 호출은 이전 스레드가 패닉 발생을 나타내는 오류를 반환합니다. 이는 손상을 명시적이고 감지 가능하게 만들지만, RefCell의 손상은 조용하게 발생합니다. 따라서 MutexGuard는 실제로 !UnwindSafe이지만, 오염 메커니즘은 RefCell이 부족한 안전한 복구 경로를 제공합니다.