WorkQueueGeneric's platformInvalidate() can deadlock when called on the RunLoop's thread

[Zan Dobersek]

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

[Carlos Garcia Campos]

I think we can get rid of the terminate condition/mutex. It's ok to detach a running thread, and platformInvalidate is called from the destructor, so we don't need to protect the m_runLoop. Tasks take their own reference so it's not possible to have pending tasks at the point either.

[Michael Catanzaro]

I think Yusuke wrote this code; let's see what he thinks.

[Yusuke Suzuki]

I think we do not need to wait thread stop. Calling the detach thread ensures that the resources will be destroyed when the thread finishes.

[Yusuke Suzuki]

Created attachment 297944 [details]
Patch

[Yusuke Suzuki]

Created attachment 297945 [details]
Patch

[Carlos Garcia Campos]

Comment on attachment 297945 [details]
Patch

Thanks!

[Yusuke Suzuki]

Comment on attachment 297945 [details]
Patch

Thanks :)

[WebKit Commit Bot]

Comment on attachment 297945 [details]
Patch

Clearing flags on attachment: 297945

Committed r210271: <http://trac.webkit.org/changeset/210271>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.