[Webkit-unassigned] [Bug 166645] New: WorkQueueGeneric's platformInvalidate() can deadlock when called on the RunLoop's thread

[bugzilla-daemon at webkit.org]

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

            Bug ID: 166645
           Summary: WorkQueueGeneric's platformInvalidate() can deadlock
                    when called on the RunLoop's thread
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Web Template Framework
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: zan at falconsigh.net
                CC: cgarcia at igalia.com

It's possible that a WorkQueue object is destroyed on its own thread. In case of the WorkQueueGeneric implementation, that is the thread of the underlying RunLoop object.

When that occurs, platformInvalidate() in WorkQueueGeneric.cpp stops the RunLoop and then waits for a signal on the m_terminateRunLoopCondition indefinitely. That doesn't occur because the signal is supposed to be launched on the same thread after the RunLoop is stopped.
https://trac.webkit.org/browser/trunk/Source/WTF/wtf/generic/WorkQueueGeneric.cpp#L68

One solution is to not wait on m_terminateRunLoopCondition if we detect that we're on the RunLoop's thread. Another solution is to remove both m_terminateRunLoopCondition and the accompanying mutex.

First reported at https://github.com/Metrological/WebKitForWayland/pull/170

-- 
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/20170103/acc44fe0/attachment.html>