본문으로 건너뛰기

[triton] Fork된 서브프로세스에서 간헐적 SIGABRT 충돌 수정

PR 링크: triton-lang/triton#9721 상태: Merged | 변경: +6 / -0

들어가며

Triton은 커널 컴파일을 서브프로세스에서 수행하는데, Python의 fork()로 생성된 자식 프로세스에서 간헐적으로 SIGABRT가 발생하는 문제가 있었습니다. 원인은 LLVM의 전역 스레드 풀이 fork-safe하지 않기 때문입니다.

핵심 코드 분석

Before

// LLVM 초기화만 수행, 스레드 풀 설정 없음
llvm::InitializeAllTargetInfos();
llvm::InitializeAllTargets();
llvm::InitializeAllAsmParsers();
llvm::InitializeAllAsmPrinters();

After

llvm::InitializeAllTargetInfos();
llvm::InitializeAllTargets();
llvm::InitializeAllAsmParsers();
llvm::InitializeAllAsmPrinters();

// LLVM 내부 병렬 처리 비활성화
// Triton 커널은 작은 LLVM 모듈이므로 pass 수준 병렬화 불필요
// fork된 자식은 스레드 풀 상태를 상속하지만 스레드는 상속하지 않아 SIGABRT 발생
llvm::parallel::strategy = llvm::hardware_concurrency(1);

왜 이게 좋은가

  1. 근본 원인 해결: fork 후 스레드 풀의 불일치 상태를 원천 차단합니다.
  2. 성능 영향 없음: Triton 커널은 작은 LLVM 모듈이므로 pass 수준 병렬화의 이점이 없습니다.
  3. 간결한 수정: 주석까지 포함해 6줄로 간헐적 크래시를 해결합니다.

정리

fork-safe하지 않은 LLVM 글로벌 스레드 풀로 인한 간헐적 SIGABRT를 단일 설정으로 해결한 PR입니다. fork()와 전역 스레드 풀은 알려진 안티패턴이며, 이 수정은 그 교훈을 잘 보여줍니다.

참고 자료


이 글은 AI(Claude)의 도움을 받아 작성되었으며, 원본 PR의 코드 변경 사항을 기반으로 분석한 내용입니다.

댓글

관련 포스트

PR Analysis 의 다른글