[webkit-changes] [WebKit/WebKit] f659df: [Win] Fix Wasm Compilation From Web Worker

[Ian]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: f659dfd725626675c2e258e2b71b6ee9d037b330
      https://github.com/WebKit/WebKit/commit/f659dfd725626675c2e258e2b71b6ee9d037b330
  Author: Ian Grunert <ian.grunert at gmail.com>
  Date:   2024-08-29 (Thu, 29 Aug 2024)

  Changed paths:
    M Source/WTF/wtf/RunLoop.h
    M Source/WTF/wtf/win/RunLoopWin.cpp
    M Source/WebCore/workers/WorkerRunLoop.cpp

  Log Message:
  -----------
  [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



To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications