REGRESSION(313609@main): visionOS debug uid 1 == main thread invariant
WTF의 Thread와 WorkQueue는 단조 증가하는 UID 네임스페이스를 공유합니다. main work queue의 mainThreadID는 1로 하드코딩되어 있습니다. IDB, DOMCacheEngine, NativePromise resolution 전반에 걸쳐 있는 sequence 안전성 assertion들은 main thread의 Thread::uid() 역시 1이라는 불변 조건에 의존합니다. 이 수정 이전에는 UID 할당이 순서에 따라 결정되었습니다. 즉, Thread 객체를 가장 먼저 생성한 thread가 uid 1을 가져갔습니다.
Source/WTF/wtf/Threading.h
Source/WTF/wtf/posix/ThreadingPOSIX.cpp
Source/WTF/wtf/MainThread.cpp
visionOS debug 환경에서는 CStringBuffer 생성자 내부의 RefCountDebugger 경로가 initializeMainThread() 실행 전에 libxpc bootstrap queue에서 Thread::currentSingleton()을 호출했습니다. 그 결과 uid 1을 선점하게 되어 실제 main thread는 uid 2를 받게 되었습니다. 이번 수정에서는 IsMain enum이 도입되었습니다. Cocoa 플랫폼에서는 pthread_main_np()를 사용해 main thread를 안정적으로 감지하도록 변경되었고, 이 불변 조건을 강제하는 RELEASE_ASSERT도 추가되었습니다.
Significance
uid 1 == main thread 불변 조건은 WebKit의 전체 concurrency model에서 핵심적인 역할을 합니다. uid가 탈취되면 무관한 코드 경로에서 RELEASE_ASSERT가 조용히 오동작하고, crash가 엉뚱한 위치에서 발생하여 실제 threading 버그가 은폐됩니다.
Audit directions
Windows와 generic POSIX에서는 IsMain::Unknown 경로가 여전히 시작 순서에 의존합니다. 향후 initializeMainThread() 실행 전에 non-main thread에서 Thread를 생성하는 코드가 추가되면 uid 1이 잘못 할당되고, 시작 시점에 RELEASE_ASSERT가 발생할 수 있습니다. ScriptExecutionContextDispatcher 리팩터링에서는 magic-number uid 비교를 isMainThread()로 대체했습니다. 다만 USE(WEB_THREAD)를 사용하는 플랫폼에서는 isMainThread()가 UI thread와 WebKit WebThread 모두에서 true를 반환합니다. 이는 Thread 생성자가 pthread_main_np()를 통해 명시적으로 피하려 했던 모호함과 동일한 문제입니다. 새로운 isCurrent() 로직이 모든 dispatch 시나리오에서 WebThread identity를 올바르게 처리하는지 살펴볼 필요가 있습니다.