[Win] Fix Wasm Compilation From Web Worker

[iangrunert]

f659dfd

[Win] Fix Wasm Compilation From Web Worker
https://bugs.webkit.org/show_bug.cgi?id=267323

Reviewed by Yusuke Suzuki.

We were calling SetTimer from the wasm compilation thread, which isn't
the thread that owns the run loop message window. That silently failed,
the timer wass never registered / fires as it's on the wrong thread.

In addition - the WorkerRunLoop was not cycling the window message pump
run loop - on other platforms this worked as both run loops used similar
message queue mechanisms.

We could fix this through wrapping timer start operations in a run loop
dispatch(), but that increases complexity through introducing another
source / type of async tasks in the loop. There's also a number of call
sites, and the risk of additional call sites being added with Windows
being the only platform where TimerBase::start() must be called on the
run loop thread.

We could also fix this through using run loop dispatch inside
TimerBase::start() / TimerBase::stop() - however it's difficult to
capture the TimerBase safely for the dispatch lambda with various
subclasses of TimerBase involved. This is necessary because the dispatch
introduces cases where the timer is destroyed before the dispatch
callback runs.

The solution used here is to make RunLoopWin PostMessage to the window
for scheduling / killing timers, so it can call SetTimer / KillTimer
from the correct thread. A HashSet is used in addition to keep track
of live timers - as sometimes a timer is able to fire but not have the
WM_TIMER event processed before KillTimer (and the timer destructor
running).

WorkerRunLoop calls RunLoop::cycle, and adjusts it's timeout based on
when the next deferredWorkTimer will fire.

* Source/WTF/wtf/RunLoop.h:
* Source/WTF/wtf/win/RunLoopWin.cpp:
(WTF::RunLoop::wndProc):
(WTF::RunLoop::TimerBase::start):
(WTF::RunLoop::TimerBase::stop):
* Source/WebCore/workers/WorkerRunLoop.cpp:
(WebCore::WorkerDedicatedRunLoop::runInMode):

Canonical link: https://commits.webkit.org/282906@main

4152509

Misc	iOS, visionOS, tvOS & watchOS	macOS	Linux	Windows
✅ 🧪 style	✅ 🛠 ios	✅ 🛠 mac	✅ 🛠 wpe	✅ 🛠 wincairo
✅ 🧪 bindings	✅ 🛠 ios-sim	✅ 🛠 mac-AS-debug	✅ 🧪 wpe-wk2	✅ 🧪 wincairo-tests
✅ 🧪 webkitperl	✅ 🧪 ios-wk2	✅ 🧪 api-mac	✅ 🧪 api-wpe
	✅ 🧪 ios-wk2-wpt	✅ 🧪 mac-wk1	✅ 🛠 wpe-cairo
✅ 🛠 🧪 jsc	✅ 🧪 api-ios	✅ 🧪 mac-wk2	✅ 🛠 gtk
✅ 🛠 🧪 jsc-arm64	✅ 🛠 vision	✅ 🧪 mac-AS-debug-wk2	✅ 🧪 gtk-wk2
	✅ 🛠 vision-sim	✅ 🧪 mac-wk2-stress	✅ 🧪 api-gtk
✅ 🛠 🧪 merge	✅ 🧪 vision-wk2	✅ 🧪 mac-intel-wk2	✅ 🛠 jsc-armv7
	✅ 🛠 tv		✅ 🧪 jsc-armv7-tests
	✅ 🛠 tv-sim
	✅ 🛠 watch
	✅ 🛠 watch-sim

[webkit-early-warning-system]

EWS run on previous version of this PR (hash 29b445b)

Misc	iOS, visionOS, tvOS & watchOS	macOS	Linux	Windows
❌ 🧪 style	✅ 🛠 ios	✅ 🛠 mac	✅ 🛠 wpe	✅ 🛠 wincairo
✅ 🧪 bindings	✅ 🛠 ios-sim	✅ 🛠 mac-AS-debug	🧪 wpe-wk2	🧪 wincairo-tests
✅ 🧪 webkitperl	⏳ 🧪 ios-wk2	🧪 api-mac	🧪 api-wpe
	⏳ 🧪 ios-wk2-wpt	🧪 mac-wk1	✅ 🛠 wpe-cairo
🛠 🧪 jsc	⏳ 🧪 api-ios	🧪 mac-wk2	✅ 🛠 gtk
✅ 🛠 🧪 jsc-arm64	✅ 🛠 vision	🧪 mac-AS-debug-wk2	🧪 gtk-wk2
	✅ 🛠 vision-sim	🧪 mac-wk2-stress	⏳ 🧪 api-gtk
	✅ 🧪 vision-wk2		✅ 🛠 jsc-armv7
	🛠 tv		✅ 🧪 jsc-armv7-tests
	✅ 🛠 tv-sim
	🛠 watch
	🛠 watch-sim

[webkit-early-warning-system]

EWS run on previous version of this PR (hash 962cfb9)

Misc	iOS, visionOS, tvOS & watchOS	macOS	Linux	Windows
✅ 🧪 style	✅ 🛠 ios	✅ 🛠 mac	✅ 🛠 wpe	✅ 🛠 wincairo
✅ 🧪 bindings	✅ 🛠 ios-sim	✅ 🛠 mac-AS-debug	✅ 🧪 wpe-wk2	✅ 🧪 wincairo-tests
✅ 🧪 webkitperl	✅ 🧪 ios-wk2	✅ 🧪 api-mac	✅ 🧪 api-wpe
	✅ 🧪 ios-wk2-wpt	✅ 🧪 mac-wk1	✅ 🛠 wpe-cairo
✅ 🛠 🧪 jsc	✅ 🧪 api-ios	✅ 🧪 mac-wk2	✅ 🛠 gtk
✅ 🛠 🧪 jsc-arm64	✅ 🛠 vision	✅ 🧪 mac-AS-debug-wk2	✅ 🧪 gtk-wk2
	✅ 🛠 vision-sim	✅ 🧪 mac-wk2-stress	✅ 🧪 api-gtk
	✅ 🧪 vision-wk2	⏳ 🧪 mac-intel-wk2	✅ 🛠 jsc-armv7
	✅ 🛠 tv		✅ 🧪 jsc-armv7-tests
	✅ 🛠 tv-sim
	✅ 🛠 watch
	✅ 🛠 watch-sim

[Constellation]

r=me

[fujii]

Is this accessing m_liveTimers from multiple threads without locking?

[iangrunert]

m_runLoop->m_loopLock is held here and inside RunLoop::TimerBase::stop when we call m_liveTimers.remove.

The m_runLoop->m_loopLock isn't held when we do the m_liveTimers.contains check inside wndProc. I could take the m_runLoop->m_loopLock there as well - if it's live we take it after we call timerFired() anyway.

[webkit-early-warning-system]

EWS run on previous version of this PR (hash a7ddab5)

Misc	iOS, visionOS, tvOS & watchOS	macOS	Linux	Windows
✅ 🧪 style	✅ 🛠 ios	✅ 🛠 mac	🛠 wpe	🛠 wincairo
✅ 🧪 bindings	✅ 🛠 ios-sim	✅ 🛠 mac-AS-debug	🧪 wpe-wk2	🧪 wincairo-tests
✅ 🧪 webkitperl	🧪 ios-wk2	⏳ 🧪 api-mac	🧪 api-wpe
	🧪 ios-wk2-wpt	🧪 mac-wk1	🛠 wpe-cairo
✅ 🛠 🧪 jsc	⏳ 🧪 api-ios	🧪 mac-wk2	🛠 gtk
✅ 🛠 🧪 jsc-arm64	✅ 🛠 vision	⏳ 🧪 mac-AS-debug-wk2	🧪 gtk-wk2
	✅ 🛠 vision-sim	🧪 mac-wk2-stress	🧪 api-gtk
	🧪 vision-wk2	⏳ 🧪 mac-intel-wk2	✅ 🛠 jsc-armv7
	🛠 tv		🧪 jsc-armv7-tests
	🛠 tv-sim
	🛠 watch
	🛠 watch-sim

[webkit-early-warning-system]

EWS run on current version of this PR (hash 4152509)

Misc	iOS, visionOS, tvOS & watchOS	macOS	Linux	Windows
✅ 🧪 style	✅ 🛠 ios	✅ 🛠 mac	✅ 🛠 wpe	✅ 🛠 wincairo
✅ 🧪 bindings	✅ 🛠 ios-sim	✅ 🛠 mac-AS-debug	✅ 🧪 wpe-wk2	✅ 🧪 wincairo-tests
✅ 🧪 webkitperl	✅ 🧪 ios-wk2	✅ 🧪 api-mac	✅ 🧪 api-wpe
	✅ 🧪 ios-wk2-wpt	✅ 🧪 mac-wk1	✅ 🛠 wpe-cairo
✅ 🛠 🧪 jsc	✅ 🧪 api-ios	✅ 🧪 mac-wk2	✅ 🛠 gtk
✅ 🛠 🧪 jsc-arm64	✅ 🛠 vision	✅ 🧪 mac-AS-debug-wk2	✅ 🧪 gtk-wk2
	✅ 🛠 vision-sim	✅ 🧪 mac-wk2-stress	✅ 🧪 api-gtk
✅ 🛠 🧪 merge	✅ 🧪 vision-wk2	✅ 🧪 mac-intel-wk2	✅ 🛠 jsc-armv7
	✅ 🛠 tv		✅ 🧪 jsc-armv7-tests
	✅ 🛠 tv-sim
	✅ 🛠 watch
	✅ 🛠 watch-sim

[webkit-commit-queue]

Committed 282906@main (f659dfd): https://commits.webkit.org/282906@main

Reviewed commits have been landed. Closing PR #32602 and removing active labels.