Make WorkerThread lifetime much more predictable.
authorbeidson@apple.com <beidson@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Thu, 30 Nov 2017 21:01:12 +0000 (21:01 +0000)
committerbeidson@apple.com <beidson@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Thu, 30 Nov 2017 21:01:12 +0000 (21:01 +0000)
commitdc3c0f0944b3d7ef16558f912b9da0e0da1683d1
tree2eec815c11fc0b4a32fb94a19c65221d7785498e
parent16e9c1e05375a8d25cf0e1eb98cf505b5eb30aa6
Make WorkerThread lifetime much more predictable.
https://bugs.webkit.org/show_bug.cgi?id=180203

Reviewed by Chris Dumez.

No new tests (Fixes flakiness in existing and future tests).

The family of classes related to Workers has a complicated ownership model.

For Dedicated Workers, the WorkerThread object is owned by the WorkerMessagingProxy,
which manages its own lifetime. Additionally, other object(s) have raw C++ references
to it, and the expected lifetimes are described in comments scattered through a few files.

What it boils down to is that the "Worker" DOM object - which lives on the main thread -
is the key to the proper destruction of all of these objects.

For ServiceWorkers running in their own context process, there is no "Worker" on the main thread.

As a result, ServiceWorkers can get into a situation where their WorkerThread can be destroyed before
their ServiceWorkerGlobalScope is destroyed on the running background thread.

There's no reason to not have WorkerThread guarantee its own lifetime until its background thread
has actually completed.

* workers/WorkerThread.cpp:
(WebCore::WorkerThread::workerThread): Protect the WorkerThread object during the entire runtime
  of the background thread itself, and release that protection on the main thread.
* workers/WorkerThread.h:

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@225343 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Source/WebCore/ChangeLog
Source/WebCore/workers/WorkerThread.cpp
Source/WebCore/workers/WorkerThread.h