Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: b432d36acad41c1e19c3f7c17ca3191a0ffd0ae3
https://github.com/WebKit/WebKit/commit/b432d36acad41c1e19c3f7c17ca3191a0ffd0ae3
Author: Ruthvik Konda <[email protected]>
Date: 2025-12-19 (Fri, 19 Dec 2025)
Changed paths:
M Source/WTF/wtf/RunLoop.h
Log Message:
-----------
Fix priority inversion in RunLoop::dispatch() by using UnfairLock
https://bugs.webkit.org/show_bug.cgi?id=304456
rdar://155316823
Reviewed by Ben Nham.
The watchdog crash in this radar (rdar://155316823) occurs due to priority
inversion.
TID 6615 (main thread) waits on m_incomingMessagesLock.
TID 7837 (com.apple.IPC.ReceiveQueue thread) holds m_incomingMessagesLock (that
6615 is waiting on) and is waiting on
m_nextIterationLock in RunLoop::dispatch().
TID 6933 (com.apple.Safari.Analytics) holds m_nextIterationLock.
But 6933 is a low priority background thread, and as a result, it's not able to
progress very quickly (which ends up leading
to the watchdog timeout). More importantly, it's holding a resource
(m_nextIterationLock) that a high priority thread (7837) needs.
This is a priority inversion problem.
m_nextIterationLock is a WTF::Lock which does not support priority inheritance.
The fix here is to make it an UnfairLock. That would boost 6933's priority as
the lock holder and allow it to progress quickly
which would release the lock and prevent the hang here.
This mirrors the fix for m_incomingMessagesLock in
https://commits.webkit.org/281223@main.
* Source/WTF/wtf/RunLoop.h:
Canonical link: https://commits.webkit.org/304775@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
