Title: [213046] releases/WebKitGTK/webkit-2.16
- Revision
- 213046
- Author
- [email protected]
- Date
- 2017-02-27 05:23:48 -0800 (Mon, 27 Feb 2017)
Log Message
Merge r212814 - [GTK] Test fast/events/message-port-postMessage-recursive.html times out
https://bugs.webkit.org/show_bug.cgi?id=168570
Reviewed by Michael Catanzaro.
Source/WTF:
This has recently been added and the patch is good. It's just revealing a problem with our timers. The test is
posting a message recursively, and also starts a timeout timer to finish the test. The timeout timer is never
fired for us, because WebCore timers have lower priority than the one used by postMessage. ScriptExecutionContext
uses Document::postTask, that uses scheduleOnMainThread, that uses RunLoop::dispatch(). We are not setting any
priority for the timer used by RunLoop::dispatch, so it's using the default.
Use a RunLoop::Timer to schedule tasks to the main thread instead of using RunLoop::dispatch(). This allows us
to use a different priority, that is now set to G_PRIORITY_HIGH_IDLE + 20 to match WebCore timers. But it also
avoids the double queue we had with RunLoop::dispatch(), because scheduleOnMainThread() also queues the tasks.
* wtf/glib/MainThreadGLib.cpp:
(WTF::MainThreadDispatcher::MainThreadDispatcher):
(WTF::MainThreadDispatcher::schedule):
(WTF::MainThreadDispatcher::fired):
(WTF::scheduleDispatchFunctionsOnMainThread):
LayoutTests:
* platform/gtk/TestExpectations:
Modified Paths
Diff
Modified: releases/WebKitGTK/webkit-2.16/LayoutTests/ChangeLog (213045 => 213046)
--- releases/WebKitGTK/webkit-2.16/LayoutTests/ChangeLog 2017-02-27 13:21:58 UTC (rev 213045)
+++ releases/WebKitGTK/webkit-2.16/LayoutTests/ChangeLog 2017-02-27 13:23:48 UTC (rev 213046)
@@ -1,3 +1,12 @@
+2017-02-22 Carlos Garcia Campos <[email protected]>
+
+ [GTK] Test fast/events/message-port-postMessage-recursive.html times out
+ https://bugs.webkit.org/show_bug.cgi?id=168570
+
+ Reviewed by Michael Catanzaro.
+
+ * platform/gtk/TestExpectations:
+
2017-02-21 Chris Dumez <[email protected]>
REGRESSION (r207720): /more/conformance/conformance/quickCheckAPI-S_V.html test fails
Modified: releases/WebKitGTK/webkit-2.16/LayoutTests/platform/gtk/TestExpectations (213045 => 213046)
--- releases/WebKitGTK/webkit-2.16/LayoutTests/platform/gtk/TestExpectations 2017-02-27 13:21:58 UTC (rev 213045)
+++ releases/WebKitGTK/webkit-2.16/LayoutTests/platform/gtk/TestExpectations 2017-02-27 13:23:48 UTC (rev 213046)
@@ -1785,8 +1785,6 @@
webkit.org/b/168569 http/tests/appcache/main-resource-fallback-for-network-error-crash.html [ Timeout ]
-webkit.org/b/168570 fast/events/message-port-postMessage-recursive.html [ Timeout ]
-
#////////////////////////////////////////////////////////////////////////////////////////
# End of Tests timing out
#////////////////////////////////////////////////////////////////////////////////////////
Modified: releases/WebKitGTK/webkit-2.16/Source/WTF/ChangeLog (213045 => 213046)
--- releases/WebKitGTK/webkit-2.16/Source/WTF/ChangeLog 2017-02-27 13:21:58 UTC (rev 213045)
+++ releases/WebKitGTK/webkit-2.16/Source/WTF/ChangeLog 2017-02-27 13:23:48 UTC (rev 213046)
@@ -1,3 +1,25 @@
+2017-02-22 Carlos Garcia Campos <[email protected]>
+
+ [GTK] Test fast/events/message-port-postMessage-recursive.html times out
+ https://bugs.webkit.org/show_bug.cgi?id=168570
+
+ Reviewed by Michael Catanzaro.
+
+ This has recently been added and the patch is good. It's just revealing a problem with our timers. The test is
+ posting a message recursively, and also starts a timeout timer to finish the test. The timeout timer is never
+ fired for us, because WebCore timers have lower priority than the one used by postMessage. ScriptExecutionContext
+ uses Document::postTask, that uses scheduleOnMainThread, that uses RunLoop::dispatch(). We are not setting any
+ priority for the timer used by RunLoop::dispatch, so it's using the default.
+ Use a RunLoop::Timer to schedule tasks to the main thread instead of using RunLoop::dispatch(). This allows us
+ to use a different priority, that is now set to G_PRIORITY_HIGH_IDLE + 20 to match WebCore timers. But it also
+ avoids the double queue we had with RunLoop::dispatch(), because scheduleOnMainThread() also queues the tasks.
+
+ * wtf/glib/MainThreadGLib.cpp:
+ (WTF::MainThreadDispatcher::MainThreadDispatcher):
+ (WTF::MainThreadDispatcher::schedule):
+ (WTF::MainThreadDispatcher::fired):
+ (WTF::scheduleDispatchFunctionsOnMainThread):
+
2017-02-20 Filip Pizlo <[email protected]>
The collector thread should only start when the mutator doesn't have heap access
Modified: releases/WebKitGTK/webkit-2.16/Source/WTF/wtf/glib/MainThreadGLib.cpp (213045 => 213046)
--- releases/WebKitGTK/webkit-2.16/Source/WTF/wtf/glib/MainThreadGLib.cpp 2017-02-27 13:21:58 UTC (rev 213045)
+++ releases/WebKitGTK/webkit-2.16/Source/WTF/wtf/glib/MainThreadGLib.cpp 2017-02-27 13:23:48 UTC (rev 213046)
@@ -30,10 +30,33 @@
#include "config.h"
#include "MainThread.h"
+#include <glib.h>
#include <wtf/RunLoop.h>
namespace WTF {
+class MainThreadDispatcher {
+public:
+ MainThreadDispatcher()
+ : m_timer(RunLoop::main(), this, &MainThreadDispatcher::fired)
+ {
+ m_timer.setPriority(G_PRIORITY_HIGH_IDLE + 20);
+ }
+
+ void schedule()
+ {
+ m_timer.startOneShot(0);
+ }
+
+private:
+ void fired()
+ {
+ dispatchFunctionsFromMainThread();
+ }
+
+ RunLoop::Timer<MainThreadDispatcher> m_timer;
+};
+
void initializeMainThreadPlatform()
{
}
@@ -40,7 +63,10 @@
void scheduleDispatchFunctionsOnMainThread()
{
- RunLoop::main().dispatch(std::function<void()>(dispatchFunctionsFromMainThread));
+ // Use a RunLoop::Timer instead of RunLoop::dispatch() to be able to use a different priority and
+ // avoid the double queue because dispatchOnMainThread also queues the functions.
+ static MainThreadDispatcher dispatcher;
+ dispatcher.schedule();
}
} // namespace WTF
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
