Bug 138831 – [GTK] Use GMainLoopSource in WebKitTestRunner

• Component: Tools / Tests
• Status: RESOLVED FIXED

[Carlos Garcia Campos]

Instead of g_timeout_add().

[Carlos Garcia Campos]

Created attachment 241782 [details]
Patch

[Sergio Villar Senin]

Comment on attachment 241782 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=241782&action=review

> Tools/WebKitTestRunner/gtk/TestControllerGtk.cpp:70
> +    }, std::chrono::duration_cast<std::chrono::microseconds>(std::chrono::duration<double>(timeout)));

I think you forgot to remove the timeoutCallback static function now that you have the lambda.

[Carlos Garcia Campos]

(In reply to comment #2)
> Comment on attachment 241782 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=241782&action=review
> 
> > Tools/WebKitTestRunner/gtk/TestControllerGtk.cpp:70
> > +    }, std::chrono::duration_cast<std::chrono::microseconds>(std::chrono::duration<double>(timeout)));
> 
> I think you forgot to remove the timeoutCallback static function now that
> you have the lambda.

Right!

[Carlos Garcia Campos]

Committed r176566: <http://trac.webkit.org/changeset/176566>

[Carlos Alberto Lopez Perez]

(In reply to comment #4)
> Committed r176566: <http://trac.webkit.org/changeset/176566>

This broke the performance bot.
Reported here: https://bugs.webkit.org/show_bug.cgi?id=139122

[WebKit Commit Bot]

Re-opened since this is blocked by bug 139124

[Carlos Alberto Lopez Perez]

I reverted r176566 on r176591 <https://trac.webkit.org/r176591> after talking with Carlos Garcia.

[Carlos Garcia Campos]

(In reply to comment #7)
> I reverted r176566 on r176591 <https://trac.webkit.org/r176591> after
> talking with Carlos Garcia.

Ok, I forgot to handle the case of no-timeout :-P. I'll land a right version.

[Carlos Garcia Campos]

Committed r176921: <http://trac.webkit.org/changeset/176921>

[Alexey Proskuryakov]

Comment on attachment 241782 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=241782&action=review

> Tools/WebKitTestRunner/InjectedBundle/gtk/TestRunnerGtk.cpp:52
> +    m_waitToDumpWatchdogTimer.scheduleAfterDelay("[WTR] waitToDumpWatchdogTimerCallback", [this] { waitToDumpWatchdogTimerFired(); },
> +        std::chrono::duration_cast<std::chrono::microseconds>(std::chrono::duration<double>(waitToDumpWatchdogTimerInterval)));

waitToDumpWatchdogTimerInterval is 30, for 30 seconds. Is the cast to microseconds the right one here?

> Tools/WebKitTestRunner/gtk/TestControllerGtk.cpp:71
>      gtk_main();

Ditto, why microseconds?

[Carlos Garcia Campos]

(In reply to comment #10)
> Comment on attachment 241782 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=241782&action=review
> 
> > Tools/WebKitTestRunner/InjectedBundle/gtk/TestRunnerGtk.cpp:52
> > +    m_waitToDumpWatchdogTimer.scheduleAfterDelay("[WTR] waitToDumpWatchdogTimerCallback", [this] { waitToDumpWatchdogTimerFired(); },
> > +        std::chrono::duration_cast<std::chrono::microseconds>(std::chrono::duration<double>(waitToDumpWatchdogTimerInterval)));
> 
> waitToDumpWatchdogTimerInterval is 30, for 30 seconds. Is the cast to
> microseconds the right one here?

Yes, the scheduleAfterDelay() version that receives the delay in microseconds creates a glib source using microseconds. For this particular case we could use milliseconds, but we moved all sources using a double value to microseconds to avoid truncations (we had cases in which timers were scheduled immediately because the conversion to milliseconds was 0, see bug #137782).

> > Tools/WebKitTestRunner/gtk/TestControllerGtk.cpp:71
> >      gtk_main();
> 
> Ditto, why microseconds?