[Webkit-unassigned] [Bug 151391] [GLIB] Implement garbage collector timers

[bugzilla-daemon at webkit.org]

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

--- Comment #10 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to comment #9)
> Comment on attachment 265749 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=265749&action=review
> 
> >>> Source/JavaScriptCore/heap/EdenGCActivityCallback.cpp:33
> >>> +#if USE(CF) || USE(GLIB)
> >> 
> >> Is USE(GLIB) also true for EFL? I wonder if it wouldn't be better to be more explicit here for the sake of code readability and leave this as:
> >> 
> >> #if USE(CF) || PLATFORM(EFL) || USE(GLIB)
> > 
> > Yes, it's true.
> 
> Why USE(GLIB) then? It's true for both EFL and GTK, but the implementations
> of HeapTimer differ for the two ports.
> 
> Since all these classes are based on HeapTimer, I think the PLATFORM(EFL) ||
> PLATFORM(GTK) should be used throughout this patch, instead of bundling them
> under USE(GLIB).

Because this would work for any other port using glib, like WebKit4Wayland, EFL is the exception here, not glib.

> > Source/JavaScriptCore/heap/HeapTimer.cpp:41
> >  #if PLATFORM(EFL)
> >  #include <Ecore.h>
> > +#elif USE(GLIB)
> > +#include <glib.h>
> >  #endif
> 
> Just one example, you end up doing this. It's counter-intuitive because
> PLATFORM(EFL) falls under USE(GLIB), but you still have to special-case it
> because of the different implementations.

Yes, because EFL uses GLIB but its own timer implementation. The EFL implementation is specific to EFL, but the GLIB one is not specific to GTK.

> > Source/JavaScriptCore/heap/HeapTimer.cpp:174
> > +    g_source_attach(m_timer.get(), g_main_context_get_thread_default());
> 
> As it stands these timers only fire on main threads, since worker threads
> aren't run via a main loop.

g_main_context_get_thread_default() will return the main thread context from threads not using a main loop in any case. But I could use the main context here to make it explicit.

-- 
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/20151119/2c8eec08/attachment-0001.html>