[Webkit-unassigned] [Bug 30876] New: [GTK] Make timeout callbacks hold the GDK lock

[bugzilla-daemon at webkit.org]

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

           Summary: [GTK] Make timeout callbacks hold the GDK lock
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKit Gtk
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: xan.lopez at gmail.com
                CC: ggaren at apple.com


Timeouts, idles, and other similar things are not executed holding the GDK lock
(since they are implemented in glib, which does not have access to that). In
multithreaded GTK+ applications only one thread can use GTK+ at any given
moment, so if you use timeouts or idles you need to be careful and hold the GDK
lock if you are going to call GTK+ APIs. WebKitGTK+ is multithreaded, so this
applies to us.

I have identified three timeouts in our codebase, all of them not holding the
GDK lock. Two are in the DRT app, and the other one is the timeout used to
schedule functions to be called in the main thread. I guess the DRT changes are
uncontroversial, but kov fears that making the other timeout hold the lock
could be a performance regression in some cases. It seems to me, though, that
there are some obvious (?) situations where JS will end up calling GTK+, like
window.open, so I if I'm not wrong we have to either a) do this b) identify all
the places that can be called from JS and protect them with locks. b) is
similar to our current situation with calling webkit_init on demand, which
seems to be a healthy source of bugs.

I'm CCing ggaren and posting my proposed patch to kick off some discussion.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.