Removed the 50ms rescheduling timeout from callOnMainThread
authorggaren@apple.com <ggaren@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Wed, 24 Jun 2020 16:38:42 +0000 (16:38 +0000)
committerggaren@apple.com <ggaren@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Wed, 24 Jun 2020 16:38:42 +0000 (16:38 +0000)
https://bugs.webkit.org/show_bug.cgi?id=213560

Reviewed by Anders Carlsson.

This is a step toward making the engine less flaky by unifying
callOnMainThread with RunLoop::dispatch.

The timeout was added in r40888 to avoid a hang under heavy postMessage
load. A few reasons this isn’t the right approach anymore:

(1) postMessage has migrated to EventLoop, which does its own
scheduling.

(2) postMessage does not use the application process RunLoop in Modern
WebKit.

(3) Delay is not a sufficient solution to a messaging hang — because
you’ll just OOM crash instead. The original author noted this problem
in bug 23705 but never resolved it; and we rediscovered it in r233111.

I verified manually that the r40888 version of
fast/workers/worker-timeout.html does not hang.

* wtf/MainThread.cpp:
(WTF::dispatchFunctionsFromMainThread):

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@263461 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Source/WTF/ChangeLog
Source/WTF/wtf/MainThread.cpp

index 8191d1a..0779714 100644 (file)
@@ -1,3 +1,32 @@
+2020-06-24  Geoffrey Garen  <ggaren@apple.com>
+
+        Removed the 50ms rescheduling timeout from callOnMainThread
+        https://bugs.webkit.org/show_bug.cgi?id=213560
+
+        Reviewed by Anders Carlsson.
+
+        This is a step toward making the engine less flaky by unifying
+        callOnMainThread with RunLoop::dispatch.
+
+        The timeout was added in r40888 to avoid a hang under heavy postMessage
+        load. A few reasons this isn’t the right approach anymore:
+
+        (1) postMessage has migrated to EventLoop, which does its own
+        scheduling.
+
+        (2) postMessage does not use the application process RunLoop in Modern
+        WebKit.
+
+        (3) Delay is not a sufficient solution to a messaging hang — because
+        you’ll just OOM crash instead. The original author noted this problem
+        in bug 23705 but never resolved it; and we rediscovered it in r233111.
+
+        I verified manually that the r40888 version of
+        fast/workers/worker-timeout.html does not hang.
+
+        * wtf/MainThread.cpp:
+        (WTF::dispatchFunctionsFromMainThread):
+
 2020-06-23  Geoffrey Garen  <ggaren@apple.com>
 
         Remove WTF::setMainThreadCallbacksPaused
index 65fff16..dd0ceea 100644 (file)
@@ -66,15 +66,10 @@ bool canCurrentThreadAccessThreadLocalData(Thread& thread)
 }
 #endif
 
-// 0.1 sec delays in UI is approximate threshold when they become noticeable. Have a limit that's half of that.
-static constexpr auto maxRunLoopSuspensionTime = 50_ms;
-
 void dispatchFunctionsFromMainThread()
 {
     ASSERT(isMainThread());
 
-    auto startTime = MonotonicTime::now();
-
     Function<void ()> function;
 
     while (true) {
@@ -90,15 +85,6 @@ void dispatchFunctionsFromMainThread()
 
         // Clearing the function can have side effects, so do so outside of the lock above.
         function = nullptr;
-
-        // If we are running accumulated functions for too long so UI may become unresponsive, we need to
-        // yield so the user input can be processed. Otherwise user may not be able to even close the window.
-        // This code has effect only in case the scheduleDispatchFunctionsOnMainThread() is implemented in a way that
-        // allows input events to be processed before we are back here.
-        if (MonotonicTime::now() - startTime > maxRunLoopSuspensionTime) {
-            scheduleDispatchFunctionsOnMainThread();
-            break;
-        }
     }
 }