Introduce SharedTimebase and stop sending time updates every 100ms

1feeb18

WebKit의 multi-process 모델에서 미디어 디코딩은 GPU process가, JS 실행은 WebContent process가 각각 담당합니다. video.currentTime 조회는 IPC round-trip 없이 동기적으로 응답해야 합니다. 기존에는 GPU가 MediaTimeUpdateData anchor를 초당 약 4회 전송했고, TimeProgressEstimator가 이를 캐싱하여 보간하는 방식이었습니다. 새로 도입된 SharedTimebase는 소규모 SharedMemory 영역을 두 process에 매핑합니다. GPU 측은 writer를, WebContent 측은 SharedTimebaseReader를 각각 보유하며, 읽기는 SequenceLocked<T>(seqlock)를 통해 lock-free로 이루어집니다.

Source/WebCore/platform/SharedTimebase.h (new)

+struct Snapshot {
+    MediaTime currentTime;
+    double playbackRate;
+    MonotonicTime hostTime;
+};
+class SharedTimebase : public RefCounted<SharedTimebase> { ... };

Source/WebKit/WebProcess/GPU/media/AudioVideoRendererRemote.cpp

-    TimeProgressEstimator m_timeEstimator;
+    std::unique_ptr<SharedTimebaseReader> m_sharedTimebaseReader;
+    std::optional<MediaTime> m_stallCap;

동일한 commit에서, AVFoundation이 rate를 0→nonzero로 잘못 보고하는 문제도 함께 처리되었습니다. 세분화된 time observer를 source 단에 적용하여 이를 마스킹했습니다. 또한 stall cap은 삭제된 TimeProgressEstimator 내부 클래스에서 m_lock 하의 AudioVideoRendererRemote 자체로 이동되었습니다.

Significance

활성 media element마다 발생하던 지속적인 IPC noise가 제거됩니다. 동시에 WebContent process가 IPC message validation 없이 직접 읽는 새로운 cross-process shared-memory 인터페이스가 도입되었으며, 이는 성능 향상에 더해 신뢰 경계에 의미 있는 변화를 가져옵니다.

Audit directions

Cross-process shared-memory 신뢰 경계를 점검해야 합니다. GPU process가 기록하는 Snapshot 값은 IPC validation 없이 WebContent로 전달됩니다. video.currentTime에 의존하는 JS 관찰 가능 동작 — MSE monitorSourceBuffers, EME timing, requestVideoFrameCallback, stall 감지 — 은 모두 이 reader를 경유합니다. GPU process가 침해된 경우, 공격자는 WebContent의 시간 인식에 직접 악의적인 anchor를 기록할 수 있습니다.

SequenceLocked<T>가 프로세스 경계를 넘어 정상적으로 동작하려면 몇 가지 조건이 필요합니다. 모든 store에 release barrier가, 모든 load에 acquire barrier가 있어야 하며, sequence count 불일치 시에는 retry loop도 필수입니다. barrier가 누락되거나 잘못 배치된 경우 — 특히 Arm에서 컴파일러 최적화 이후 — torn read가 발생할 가능성이 있습니다. 이 경우 write N의 currentTime과 write N+1의 hostTime이 쌍을 이루는 상황이 생깁니다.

m_stallCap은 notifyTimeReachedAndStall에서 설정됩니다. cancelTimeReachedAction에서는 무조건 해제되며, cancelPendingSeek에서는 seek 방향에 따라 조건부로 해제됩니다. seek 방향에 따른 조건 처리가 역방향 seek, rate=0 seek, stall이 이미 발생한 뒤 도착하는 seek에 대해서도 올바르게 동작하는지 점검이 필요합니다.

SharedTimebase::create()는 SharedMemory::allocate 실패 시 nullptr을 반환합니다. Create reply와 async error dispatch 사이의 race 조건으로 인해 m_sharedTimebaseReader가 null인 상태가 생길 수 있습니다. 이 상태에서 currentTime()이나 effectiveRate()를 역참조하면 crash가 발생합니다.

마지막으로 maxExtrapolation의 silent clamp 문제입니다. GPU process가 cap보다 오래 stall되는 경우, video.currentTime을 polling하여 hang을 감지하는 애플리케이션이 잘못된 정보를 받게 될 가능성이 있습니다.