GN⁺: 아마도 Rust는 대규모 동시성 사용자 공간 소프트웨어에 적합한 도구가 아닐 수 있음
(bitbashing.io)- 본 기사는 대규모 동시성을 가진 사용자 공간 소프트웨어에 Rust를 사용하는 데 있어서의 도전을 논의한다.
- Rust의 비동기 모델은 현대 컴퓨팅의 두 가지 핵심 개념인 동시성과 병렬성을 처리하도록 설계되었다.
- 병렬성은 여러 CPU에서 코드를 동시에 실행하는 것을 포함한다.
- 동시성은 문제를 분리하고, 독립적인 부분으로 나누어 순서에 상관없이 또는 부분적인 순서로 실행하는 것을 포함한다.
- 본 기사는 비싼 프로세스 간 통신 때문에 동시성을 위해 여러 프로세스를 사용하는 것의 한계를 강조한다.
- 같은 메모리를 공유하는 프로세스인 스레드가 대안으로 제시되지만, 경쟁 조건과 교착 상태와 같은 복잡한 문제를 초래할 수 있다.
- Tony Hoare의 1978년 논문 "Communicating Sequential Processes"는 스레드가 서로에게 메시지를 보내는 데 대기열 또는 채널을 사용하는 것을 제안하였으며, 프로세스와 같은 격리와 쉬운 디버깅과 같은 여러 가지 장점을 제공한다.
- Rust의 표준 라이브러리에는
std::sync::mpsc::sync_channel아래에 채널이 포함되어 있다. - 그러나 수만 명의 사용자에 연결된 웹 서버와 같은 높은 수준의 동시성을 요구하는 문제에 대해서는 스레드가 충분하지 않을 수 있다.
- Rust는 이러한 상황에 대해 함수가 비동기로 표시되면 미래 또는 약속을 반환하고 결과를 생성하기 위해 대기할 수 있는 "async/await" 모델을 사용한다.
- 그 장점에도 불구하고, 비동기 Rust는 컴파일러에게 모든 것이 괜찮을 것이라는 것을 확신시키는 필요성과 같은 도전이 있다. 이는 원시 스레드로는 어려울 수 있다.
- "원자 참조 카운트" 또는 Arc의 사용이 해결책으로 제안되지만, 가비지 수집기의 문제와 유사한 문제를 초래할 수 있어 만병통치약이 아니다.
- 본 기사는 Rust가 다른 영역에서의 강점에도 불구하고, 대규모 동시성을 가진 사용자 공간 소프트웨어에 대한 최적의 도구가 아닐 수 있다는 것을 제안하며 마무리한다.
Hacker News 의견
- 저자는 실시간으로 대량의 데이터를 처리해야 하는 고성능 메타버스 클라이언트를 Rust로 개발 중입니다.
- 저자의 프로젝트는 그래픽 렌더링, 네트워크 이벤트 처리, 자산 로딩 등 다양한 작업을 위해 여러 스레드를 사용합니다.
- Rust는 이 프로젝트에 유익하였으며, 저자는 보통 다른 사람의 "안전하지 않은" 코드 때문에 일년에 한 번 메모리 관련 충돌을 경험하였습니다.
- 저자는 Rust가 레이스 컨디션은 없지만 데드락은 없지 않다고 비판하며, 정적 데드락 분석기의 필요성을 제안합니다.
- 저자는 Rust에서 async의 널리 사용을 비판하며, 이것이 계산에 묶인 작업에 적합하지 않고 여러 우선 순위에서 실행되는 스레드와 호환되지 않다고 주장합니다.
- 저자는 Rust의 단일 소유권이 후방 참조와 함께 일반적인 필요성이지만 구현하기가 너무 어렵다고 제안합니다.
- 저자는 Rust 게임 생태계가 심각한 게임 개발에 준비되지 않았다고 믿으며, Rust에서 비 장난감 그래픽의 부족을 인용합니다.
- 다른 댓글들은 async Rust가 도전적이며 종종 불필요하다고 동의하며, Go의 모든 것을 sync로 만들고 단일 async 채널로 만드는 접근 방식이 더 나을 수 있다고 제안합니다.
- 일부 댓글러들은 Rust 생태계에서 async의 널리 사용을 비판하며, 이것이 프로그램을 전체적으로 async로 만들거나 많은 것들에 대해 tokio crate에 의존하도록 강요한다고 주장합니다.
- 일부 댓글러들은 Rust의 async 기능이 아직도 개발 중이며, 현재 상태를 비판하는 것은 이른 것이라고 제안합니다.
- 한 댓글러는 Rust의 Arc가 알 수 없는 것이 아니라 어디에서 어떻게 가지고 있는지에 따라 결정된다고 주장하며, 저자가 이전의 정신 모델을 Rust에 강요하려고 하고 있다고 제안합니다.
- 일부 댓글러들은 일반적으로 async/await의 사용에 반대하며, 이것이 언어와 생태계를 반으로 나누고 장기적인 문제를 일으킨다고 주장합니다.
- 한 댓글러는 병행성에 대한 올바른 원시적인 것은 Hoare의 Communicating Sequential Processes가 Java (JDK17 이후 - Java Virtual Threads), Go, Kotlin에서 구현된 것처럼 green threads에 매핑된 것이라고 제안합니다.
- 한 댓글러는 async-scoped와 같은 안전하지 않은 crate를 사용하여 C++에서 작성되었을 벌레 대부분을 잡는 것이 합리적인 타협이라고 제안합니다.