[Webkit-unassigned] [Bug 150590] [GTK] Use a persistent main loop source in RunLoop glib implementation

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=150590

Zan Dobersek <zan at falconsigh.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #264130|review?                     |review+
              Flags|                            |

--- Comment #2 from Zan Dobersek <zan at falconsigh.net> ---
Comment on attachment 264130
  --> https://bugs.webkit.org/attachment.cgi?id=264130
Patch

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

> Source/WTF/wtf/glib/RunLoopGLib.cpp:146
>      stop();
> +    g_source_destroy(m_source.get());

Is stop() still bringing anything here, given that the source is destroyed afterwards?

> Source/WTF/wtf/glib/RunLoopGLib.cpp:152
> +    gint64 current = g_get_monotonic_time();
> +    g_source_set_ready_time(m_source.get(), m_fireInterval.count() ? current + m_fireInterval.count() : current);

I'd advise special-casing the 0-microsecond delay here, which is the most common.

> gint64 delay = 0;
> if (m_fireInterval.count())
>     delay = g_get_monotonic_time() + m_fireInterval.count()
> g_source_set_ready_time(m_source.get(), delay);

That way you avoid querying the monotonic time for most cases, and 0 delay still means 'dispatch ASAP' in GLib.

> Source/WTF/wtf/glib/RunLoopGLib.cpp:157
> +    stop();

Is stop() useful here? The source's ready time is updated afterwards anyway.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20151028/bba7b743/attachment.html>