Ruby ThreadGroup 클래스 강화 및 활용 방안

[17S05] Improvement of ThreadGroup class and its usage (ja)

작성자
RubyKaigi
발행일
2025년 10월 05일

핵심 요약

  • 1 Ruby ThreadGroup 클래스의 현재 한계점을 극복하고 활용도를 높이기 위한 네 가지 주요 강화 방안이 제시되었습니다.
  • 2 스레드 그룹 간의 명확한 제어 권한(`dominate`) 설정과 예외 종료를 포함한 스레드 처리의 직렬화(`ThreadQueue`) 메커니즘이 제안되었습니다.
  • 3 스크립트 테스트 환경 및 정의 충돌 해결을 위한 폐쇄형 로컬 공간(`Local Space`) 생성 아이디어가 논의되었으나, 이는 가장 비판적인 부분으로 언급되었습니다.

도입

본 발표는 큐슈공업대학의 나가이 씨가 Ruby의 ThreadGroup 클래스 강화 및 활용 방안에 대해 논의합니다. 발표자는 Ruby 커미터로서, 현재 Ruby의 ThreadGroup이 스레드를 묶는 기본적인 기능은 제공하지만, Java와 같은 다른 언어에 비해 기능이 부족하고 스레드 그룹 간의 계층 관계나 조작 권한이 전혀 없다는 한계를 지적합니다. 이로 인해 실제 개발 현장에서 ThreadGroup의 활용도가 매우 낮으며, 이러한 '아깝다(もったいない)'는 문제의식에서 출발하여 ThreadGroup을 더욱 유용하게 만들고자 하는 동기를 설명합니다.

발표에서는 Ruby ThreadGroup 클래스의 네 가지 주요 강화 포인트를 제시하며, 이는 기존 라이브러리 방식이 아닌 코어 변경을 통해 구현되어야 하는 이유를 설명합니다. 핵심 변경 사항은 다음과 같습니다.

1. 스레드 그룹 조작성 향상

현재 ThreadGroup은 새로운 스레드를 특정 그룹에 생성하는 것조차 불편하며, 그룹 전체를 대상으로 하는 조작 메서드가 부재합니다. 이로 인해 스레드 목록을 배열로 변환 후 처리해야 하는 비효율성이 발생합니다. 이를 개선하기 위해 스레드 생성과 그룹 설정을 단일 처리로 묶는 new_thread와 같은 메서드 추가가 제안됩니다. 또한, 스레드 고유 데이터와 유사한 ThreadGroup 고유 데이터 및 스레드 폭주 방지를 위한 최대 스레드 수 제한 기능도 고려됩니다.

2. 그룹 간 조작 권한 설정

현재 ThreadGroup 간에는 아무런 권한 설정이 없어 enclosed 상태로 스레드의 이탈 및 진입을 막더라도, 그룹 내 스레드 관리를 위한 스레드를 어디에 두어야 할지 모호합니다. 관리 스레드가 그룹 내부에 있으면 혼란스럽고, 외부에 있으면 내부 스레드에 문제가 생겼을 때 제어할 수 없는 문제가 발생합니다. 이를 해결하기 위해 dominate 상태를 도입하여 특정 ThreadGroup이 다른 ThreadGroup을 지배하고 조작할 수 있는 권한을 부여하는 계층적 관계 설정이 제안됩니다. 이는 Normal → Dominated → Enclosed → Frozen의 단방향 상태 전이를 따릅니다.

3. 예외 종료를 포함한 스레드 직렬화 (ThreadQueue)

분산 처리 환경에서 여러 스레드의 종료 순서에 따른 처리가 어렵고, 예외 발생 시 즉각적인 대응이 복잡합니다. 기존 방식은 폴링이나 개별 감시 스레드를 통해 상태를 확인해야 합니다. 이를 개선하기 위해 ThreadGroup마다 ThreadQueue를 제공하여, 예외 종료를 포함한 모든 종료 스레드를 큐에 넣어 관리 스레드가 순서대로 처리할 수 있도록 합니다. thread_group_enqueue 메서드를 통해 스레드가 슬립 상태로 전환됨과 동시에 큐에 들어가도록 하여 경합 조건을 방지하고, 관리 스레드의 부담을 경감하며 제어 권한을 강화합니다. 이는 가상 쿼리 병렬 처리 및 스레드 풀 구현 예시를 통해 설명됩니다.

4. 폐쇄형 자기 공간 생성 (Local Space)

가장 비판적인 부분으로, 국소적으로 유효한 메서드 및 상수를 정의할 수 있는 Local Space 개념을 제안합니다. 이는 스레드 그룹 변경을 통해 동적으로 환경을 변경하거나, enclosed 또는 dominate 상태로 변경을 금지할 수 있습니다. 스크립트 실행 테스트 환경에서 내장 클래스 오염을 방지하거나, 샌드박스 지원, 정의 충돌 해결(예: MathN 라이브러리와 같은 전역 오염 라이브러리 공존) 등의 용도로 활용될 수 있습니다. `Fixnum

/` 메서드를 로컬로 재정의하는 예시를 통해 그 가능성을 보여줍니다. 모듈 확장이나 특별한 클래스 생성 대신 ThreadGroup에 직접 구현하는 이유를 설명하고, ThreadGroup이 GC될 때 Local Space 내용도 함께 소멸되어 라이브러리 언로드 가능성을 열 수 있다는 비전을 제시합니다.

결론

제안된 ThreadGroup 강화 방안들은 아직 상세 내용이 개정 중이며, 구현이 완료되지 않은 상태입니다. 과거 버전의 시험 구현이 Ruby-dev #43901에 존재하지만, 이는 현재의 구상과는 다릅니다. 이 제안들은 Ruby 코어에 깊이 관여하는 변경 사항이므로, 많은 비판과 함께 충분한 합의가 이루어지지 않는 한 도입이 어려울 것으로 예상됩니다. 발표자는 현재 자신의 제안이 고립된 상태임을 인정하며, 부분적으로라도 이러한 강화 방안에 공감하는 개발자들의 지지와 협력을 요청하며 발표를 마무리합니다. 이는 Ruby의 동시성 관리 기능을 한층 발전시키고자 하는 중요한 시도입니다.

댓글 0

댓글 작성

0/1000
정중하고 건설적인 댓글을 작성해 주세요.

아직 댓글이 없습니다

첫 번째 댓글을 작성해보세요!