학습 노트: Python GIL과 check-then-act 레이스 컨디션

[cmygray]

배경

#1 디버깅 과정에서 정리한 Python 멀티스레딩 학습 내용.

GIL이 있어도 레이스 컨디션은 발생한다

GIL이 보장하는 것

• 단일 바이트코드 명령어의 원자성 (예: STORE_SUBSCR — dict[key] = value)
• interpreter 내부 자료구조의 무결성 (crash 방지)

GIL이 보장하지 않는 것

• 여러 바이트코드에 걸친 논리적 원자성

check-then-act 패턴

# 이 코드는 3개의 바이트코드 명령어로 컴파일된다
if state["pressed"] and not state["holding"]:   # ① 읽기 (LOAD)
    state["holding"] = True                       # ② 쓰기 (STORE)
    on_start()                                    # ③ 부수효과 (CALL)

GIL은 ①과 ② 사이에서 스레드를 전환할 수 있다. 다른 스레드가 이 틈에 같은 state를 변경하면 논리적 불일치가 발생한다.

GIL 전환 조건

• 5ms 간격: sys.getswitchinterval() 기본값 = 0.005초
• I/O 블로킹: 파일, 네트워크, sleep 등 호출 시 즉시 전환

안전/위험 판단 기준

안전 (단일 명령)	위험 (복합 연산)
state["x"] = 1	if state["x"]: state["y"] = ...
dict[key] 단일 읽기	여러 키를 읽고 그 결과로 분기
list.append(x)	if x not in list: list.append(x)

결론

GIL은 interpreter crash 방지이지, 비즈니스 로직의 원자성 보장이 아니다. check-then-act 패턴은 언어와 무관하게 항상 lock이 필요하다.

참고

• CPython GIL 문서
• dis 모듈로 바이트코드 확인 가능: python -m dis -c "d={'a':1}; d['a']=2"

[cmygray]

macOS 앱 패키징 & pyobjc 학습 노트 (2026-03-18 세션)

1. PyInstaller + MLX 네이티브 확장 번들링

문제: collect_all("mlx")로 수집해도 mlx.metallib Metal 셰이더를 못 찾음.

원인: PyInstaller가 libmlx.dylib를 _MEIPASS 최상위에 복사하는데, C++ 코드가 dladdr로 자기 경로 기준 같은 디렉토리에서 metallib을 찾음. 실제 metallib은 mlx/lib/ 하위에 있어서 경로 불일치.

해결: 런타임 훅(pyi_rth_mlx.py)에서 symlink 생성.

배운 점: 네이티브 라이브러리가 dladdr 기반으로 리소스를 찾는 경우, PyInstaller의 바이너리 재배치가 경로를 깨뜨릴 수 있다. collect_all만으로 충분하지 않은 경우가 있다.

---

2. macOS 접근성 권한: CGPreflightListenEventAccess vs AXIsProcessTrusted

문제: 접근성 권한을 줬는데 앱이 인식 못함.

원인: CGPreflightListenEventAccess()는 입력 모니터링 (Input Monitoring) 권한을 체크한다. CGEventTapCreate의 active tap은 접근성 (Accessibility) 권한이 필요한데, 코드가 잘못된 API를 호출하고 있었다.

API	체크하는 권한
CGPreflightListenEventAccess()	입력 모니터링
AXIsProcessTrusted()	접근성
AXIsProcessTrustedWithOptions({prompt: True})	접근성 + 시스템 다이얼로그 자동 표시

배운 점: macOS 권한 모델에서 "접근성"과 "입력 모니터링"은 별개. CGEventTap의 active/passive 모드에 따라 필요한 권한이 다르다.

---

3. PyInstaller + multiprocessing: freeze_support 필수

문제: 번들 앱에서 [ttstt] 이미 실행 중입니다 메시지가 뜨면서 단일 인스턴스 락 충돌.

원인: HuggingFace Hub가 multiprocessing을 사용하는데, macOS의 "spawn" 시작 방법이 __main__.py를 재실행. freeze_support()가 없으면 자식 프로세스가 main()을 다시 호출.

해결: __main__.py 최상단에 multiprocessing.freeze_support() 추가.

배운 점: PyInstaller 번들에서 multiprocessing을 쓰는 라이브러리가 있으면 반드시 freeze_support() 호출. 직접 multiprocessing을 안 쓰더라도 의존성이 쓸 수 있다.

---

4. pyobjc NSObject 서브클래스와 Python GC 충돌

문제: 설정 창을 닫은 후 메뉴 항목 클릭 시 EXC_BREAKPOINT (SIGTRAP) — object_getClass PAC trap 크래시.

원인: pyobjc로 만든 _Delegate(NSObject) 서브클래스 인스턴스가 Python GC에 의해 해제되면, ObjC 런타임이 이미 해제된 객체를 참조하여 pointer authentication trap 발생.

시도한 것들 (실패):

• _instance = None 설정 → GC 타이밍 문제
• 모듈 레벨 _refs dict에 강한 참조 유지 → window.close() 시 ObjC 쪽에서 해제
• threading.Timer로 지연 종료 → 비메인 스레드에서 rumps.quit_application() 호출 불가
• rumps.timer로 지연 적용 → 여전히 크래시

해결: window.close() 대신 window.orderOut_(None)으로 창을 숨김. ObjC 객체가 해제되지 않으므로 GC 문제 없음. 두 번째 호출 시 기존 창을 재사용.

배운 점:

• pyobjc에서 NSObject 서브클래스를 사용할 때, Python 참조와 ObjC 참조의 수명 관리가 핵심
• window.close()는 ObjC 쪽에서 비동기적으로 객체를 해제할 수 있어 위험
• orderOut_은 숨기기만 하므로 안전. 재사용 패턴이 pyobjc에서 가장 안정적
• rumps와 pyobjc NSWindow를 혼용할 때, rumps의 메인 스레드 run loop과 충돌하지 않도록 주의

---

5. rumps 메인 스레드 블로킹 금지

문제: 설정 저장 후 핫키 재시작 시 thread.join(timeout=2.0)으로 메인 스레드 블로킹 → 이후 메뉴 클릭 시 크래시.

원인: rumps는 NSApplication.run()으로 메인 스레드의 run loop을 점유. thread.join()이 메인 스레드를 블로킹하면 AppKit 내부 상태가 손상.

해결: thread.join() 제거. stop_event.set()만 하면 옛 스레드가 CFRunLoopStop으로 자연 종료됨. 새 스레드는 즉시 시작.

배운 점: rumps(또는 NSApplication 기반) 앱에서는 메인 스레드를 절대 블로킹하면 안 된다. 스레드 정리는 비동기적으로 처리해야 한다.