질문의 역사
Rust의 타입 시스템은 생명 주기 매개변수를 "조기 바인딩" 또는 "후晚 바인딩"으로 분류합니다. 조기 바인딩 생명 주기는 정의 또는 인스턴스화 지점에서 해결되며, 항목의 존재 기간 동안 구체적이고 고정됩니다. HRTB에서 for<'a> 구문을 통해 도입된 후晚 바인딩 생명 주기는 실제 사용 지점까지 다형성이 유지되어, 함수나 특성 바인이 모든 가능한 생명 주기에 대해 균일하게 작동할 수 있도록 합니다. 이 구분은 콜백이나 클로저를 수용하는 진정한 고차 함수를 지원해야 할 필요성에서 파생되었습니다. 이는 호출자가 모든 호출에 대해 단일, 특정 생명 주기에 의존하도록 강요하지 않습니다.
문제
고차 함수가 fn process<'a, F: Fn(&'a Data)>(f: F)와 같이 생명 주기 매개변수를 명시할 때, 생명 주기 'a는 조기 바인딩이 됩니다. 이는 컴파일러가 호출 지점에서 컨텍스트에 따라 특정 생명 주기 'a를 선택하고, 클로저 타입 F는 해당 특정 'a에 대해 Fn(&'a Data)를 만족해야 함을 의미합니다. 결과적으로, 클로저는 이후 호출에서 서로 다른 생명 주기의 데이터와 재사용될 수 없으며, 빌림 지속 시간이 더 짧거나 길어지는 상황에 전달하려고 하면 생명 주기 불일치 오류가 발생합니다. 이 제한은 스레드 풀이나 이벤트 디스패처와 같은 유연하고 재사용 가능한 추상화를 생성하는 것을 효과적으로 방지합니다.
해결책
HRTB는 생명 주기 매개변수를 특성 바인드 자체로 이동시킴으로써 이를 해결합니다: fn process<F: for<'a> Fn(&'a Data)>(f: F) . 여기서 for<'a>는 타입 F가 모든 가능한 생명 주기 'a에 대해 특성을 구현해야 함을 명시합니다. 이는 생명 주기를 후晚 바인딩으로 만들어줍니다; 컴파일러는 클로저가 보편적으로 다형적임을 확인하여, 함수 본문 내 각 개별 호출 지점에서 어떤 생명 주기를 가진 참조도 수용할 수 있도록 합니다. 이 메커니즘은 콜백의 저장소와 데이터의 수명 사이의 결합을 분리하여, 다양한 실행 컨텍스트 간에 빌린 데이터를 안전하게 처리하는 제로 비용 추상화를 가능하게 합니다.
// 조기 바인딩: 'a는 호출 지점에서 고정되어 유연성을 제한합니다. fn bad_process<'a, F>(f: F) where F: Fn(&'a str) -> usize, { let local = String::from("temp"); // 오류: local은 조기 바인딩 'a와 같은 시간 동안 존재하지 않음 // f(&local); } // 후晚 바인딩: HRTB는 'a가 각 호출 시 어떤 생명 주기라도 될 수 있게 합니다. fn good_process<F>(f: F) where F: for<'a> Fn(&'a str) -> usize, { let local = String::from("temp"); // OK: 'a는 이 호출에 대해 &local의 생명 주기로 인스턴스화됩니다. println!("{}", f(&local)); } fn main() { let count_fn = |s: &str| s.len(); good_process(count_fn); }
문제 설명
고주파 거래 엔진을 위한 제로 카피 이벤트 디스패치 시스템을 설계할 때, 팀은 전략 핸들러의 레지스트리가 필요했습니다. 이 핸들러는 소유권을 가져가지 않고 시장 데이터 패킷을 검사하는 클로저로, 마이크로초 단위의 처리를 가능하게 했습니다. 중앙 디스패처는 이러한 핸들러를 HashMap<String, Box<dyn Handler>>에 저장하고, 임시적으로 수신 네트워크 버퍼의 뷰를 사용하여 호출해야 했습니다. 문제는 네트워크 버퍼의 생명 주기가 극히 짧고 범위에 바인딩되어 있는 반면, 디스패처 자체는 오래 지속되는 싱글톤이라는 점이었습니다. 핸들러 특성이 특정 생명 주기에 묶여 있다면, 디스패처는 해당 생명 주기 매개변수가 필요하게 되어, 전역 상태에 저장하거나 다양한 거래 세션을 걸쳐 생존할 수 없게 됩니다.
해결책 A: 생명 주기 매개변수를 가진 정적 디스패치
한 가지 접근 방식은 디스패처를 'a에 대해 제네릭으로 만들어 Box<dyn Handler<'a>>를 저장하는 것이었습니다. 이는 전체 디스패처 구조체가 생명 주기 'a를 지니도록 만들어, 네트워크 버퍼의 범위와 연결된 단기 객체로 만들었습니다. 장점으로는 제로 비용 추상화와 실행 시간 오버헤드가 없었습니다. 그러나 단점은 아키텍처적인 문제로 인해 디스패처를 lazy_static!에 저장하거나 독립적인 생명 주기를 가진 다른 스레드로 보내는 것이 불가능하게 되어, 세션 관리 논리를 완전히 재설계해야 했습니다.
해결책 B: 'static 경계를 통한 생명 주기 제거
다른 옵션은 핸들러로 전달되는 모든 데이터가 'static이거나 핸들러가 소유 데이터를 가져오도록 요구하는 것이었습니다(예: Vec<u8>). 이렇게 하면 핸들러를 Box<dyn Handler + 'static>으로 저장할 수 있게 되었습니다. 장점으로는 간단하고 저장이 용이하다는 점이었습니다. 하지만 단점으로는 모든 네트워크 패킷이 'static 또는 소유 상태로 승격하기 위해 메모리 할당과 복사를 요구하여, 마이크로초 지연 요구 사항을 파괴하고 높은 처리량 동안 메모리 압박을 증가시킨다는 심각한 성능 페널티가 있었습니다.
해결책 C: 고등 순위 특성 경계(HRTB)
선택된 해결책은 핸들러 특성을 HRTB를 사용하여 정의한 것입니다: trait Handler { fn handle(&self, data: &Packet); }는 F: for<'a> Fn(&'a Packet)에 대해 구현됩니다. 이는 Box<dyn Handler>를 저장할 수 있게 하며(암묵적으로 'static이기 때문에 어떤 생명 주기에도 작동할 것이라고 약속합니다) handle 호출 시 네트워크 버퍼의 일시적인 빌림을 전달할 수 있게 합니다. 장점으로는 제로 카피 성능의 보존과 오래 지속되는 전역 상태에 핸들러를 저장할 수 있는 능력이 있었습니다. 단점으로는 특성 바인드의 복잡성이 증가하고, 핸들러가 for<'a> 계약을 위반할 수 있는 환경 참조를 우연히 캡처하지 않도록 보장해야 합니다.
결과
거래 엔진은 패킷 데이터에 대해 할당 없이 초당 수백만 개의 이벤트를 성공적으로 처리했습니다. HRTB 기반 아키텍처는 팀이 서로 다른 모듈에서 핸들러를 혼합하고 일치시킬 수 있게 하였으며, 일부는 스택에서, 다른 일부는 스레드 로컬 영역에서 빌리기를 통해 컴파일러는 어떤 핸들러도 액세스한 일시적인 데이터보다 먼저 생존할 수 없도록 보장하였습니다. 이로 인해 고도로 동시적인 환경에서 데이터 경쟁과 사용 후 해제를 방지했습니다.
Box<dyn Fn(&'a T)>가 왜 포함하는 구조체에 생명 주기 매개변수를 강제하는 반면, Box<dyn for<'a> Fn(&'a T)>는 그렇지 않은가?
첫 번째 경우, 생명 주기 'a는 특성 객체 자체의 구체적인 타입 매개변수입니다. 타입 dyn Fn(&'a T)는 암묵적으로 'a 경계를 가지므로, 특성 객체는 해당 특정 생명 주기에 대해서만 유효합니다. 그러므로 이 객체를 포함하는 모든 구조체는 이 구조체가 클로저가 캡처하거나 수용할 수 있는 참조보다 더 오래 생존하지 않는다는 것을 증명하기 위해 <'a>를 선언해야 합니다. for<'a>가 있으면, 특성 객체는 클로저가 모든 생명 주기에 대해 작동한다고 주장하여, 포함자의 타입 서명에서 'a에 대한 특정 의존성을 효과적으로 제거합니다. 이는 구조체가 'static이 될 수 있게 하며, 이는 특정 빌림에 대한 링크가 아닌 보편적인 유용성 약속을 보유하기 때문입니다.
HRTB는 빌린 입력에 대한 참조를 반환하려는 클로저와 어떻게 상호 작용하는가?
후보자들은 종종 F: for<'a> Fn(&'a T) -> &'a U를 작성하려고 시도하며 입력의 생명 주기와 일치하는 출력 생명 주기를 기대합니다. 그러나 표준 Fn 특성의 연관 타입 Output은 'a에 대해 제네릭이 아니며, 클로저 타입에 대해 고정되어 있습니다. 따라서 HRTB만으로는 Fn 특성 가족 내에서 입력 인수에 묶인 생명 주기가 있는 반환 유형을 표현할 수 없습니다. 이를 달성하려면 HRTB와 함께 제네릭 연관 타입(GAT)을 사용하여 trait Processor { type Output<'a>; fn process<'a>(&self, input: &'a T) -> Self::Output<'a>; }처럼 사용자 정의 특성을 정의해야 합니다. 이 제약 사항을 이해하지 못함으로써, 후보자들은 "반환 타입이 충분히 오래 살아 있지 않음"이라는 컴파일러 오류로 어려움을 겪는 경우가 많으며, HRTB가 표준 클로저의 반환 생명 주기 문제를 해결할 수 있다고 잘못 믿고 있습니다.
함수의 생명 주리과 특성 바인드의 후晚 바인딩 생명 주기 사이의 근본적인 차이는 무엇인가?
함수가 자신의 생명 주기를 선언할 경우, 예를 들어 fn foo<'a, F: Fn(&'a T)>, 생명 주기 'a는 조기 바인딩입니다. 호출 지점에서의 모노모르파이제이션 또는 타입 검사 중에, 컴파일러는 해당 특정 호출에 대해 모든 제약 조건을 만족하는 단일, 특정 'a를 선택합니다. 그런 다음 F는 이 구체적인 'a에 대해 검사됩니다. 반면에 fn foo<F: for<'a> Fn(&'a T)>의 경우, 컴파일러는 F가 모든 가능한 생명 주기들에 대해 제약 조건을 만족하는지 확인합니다. 이는 foo 내에서 클로저를 여러 번 호출 할 수 있는 반면, 조기 바인딩 버전에서는 foo가 호출된 시점에 선택된 단일 'a로 모든 호출 제한이 이루어질 것임을 의미합니다. 후보자들은 종종 함수의 조기 바인딩 생명 주기가 해당 호출에 대한 "컴파일 시간 상수"와 같고, HRTB의 후晚 바인딩 생명 주기는 어떤 인스턴스에도 유효한 "보편적으로 양이 정해진 변수"와 같다는 사실을 놓칩니다.