To reuse the code of RemoteWorker::State and RemoteWorker::Op in RemoteWorkerNonLifeCycleOpControllerChild, this patch isolates these reused codes into a new file RemoteWorkerOp.h. And also extract RemoteWorker::SharedWorkerOp into SharedWorkerOp.h.cpp
Depends on D197563
Differential Revision: https://phabricator.services.mozilla.com/D198005
In this patch, IPC PRemoteWorkerNonLifeCycleOpController is created for non-life cycle operations of SharedWorker/ServiceWorker.
PRemoteWorkerNonLifeCycleOpController is the IPC between the content process worker thread and the parent process background thread.
This IPC helps to build a direct communication instead of go through worker launcher thread and the main thread.
Endpoint<PRemoteWorkerNonLifeCycleOpControllerParent/Child> pairs are created when RemoteWorkerManager::LaunchInternal().
The parent Endpoint is binded a RemoteWorkerNonLifeCycleOpControllerParent immediately and connect to the corresponding RemoteWorkerController.
And the child Endpoint is passed through IPC PRemoteWorkerService::SendPRemoteWorkerConstructor() to the content process, and then binds to a PRemoteWorkerNonLifeCycleOpControllerChild when the Worker gets into "Running" state.
After connection is built, RemoteWorkerController can send non-life cycle related operations by PRemoteWorkerNonLifeCycleOpController and send life cycle related operations by PRemoteWorker.
Depends on D196946
Differential Revision: https://phabricator.services.mozilla.com/D197563
This patch introduces a boolean WorkerThreadRunnable::mCleanPreStartDispatching to indicate if the WorkerThreadRunnable needs to skip its execution in its Run() because of WorkerPrivate::RunLoopNeverRan().
If any WorkerPrivate initialization fails in [[ https://searchfox.org/mozilla-central/rev/a26e972e97fbec860400d80df625193f4c88d64e/dom/workers/RuntimeService.cpp#2090-2120 | WorkerThreadPrimaryRunnable::Run() ]], corresponding WorkerJSContext might not be created or created then destroyed before entering [[ https://searchfox.org/mozilla-central/rev/a26e972e97fbec860400d80df625193f4c88d64e/dom/workers/RuntimeService.cpp#2085 | WorkerPrivate::RunLoopNeverRan() ]]. This invalidates the WorkerJSContext, and GetCurrentThreadWorkerPrivate() will not work correctly. In this case, any WorkerThreadRunnable should not run in this invalid environment, so we can just skip the execution by returning NS_OK in its Run().
To skip the execution, we need to keep WorkerPrivate::mPreStartRunnables until WorkerPrivate::DoRunLoop() or WorkerPrivate::RunLoopNeverRan() is called. If WorkerPrivate::RunLoopNeverRan() is called, WorkerThreadRunnable::mCleanPreStartDispatching is set as true, such that WorkerThreadRunnable::Run() no need to get a WorkerPrivate for status judgment.
Depends on D213946
Differential Revision: https://phabricator.services.mozilla.com/D213947
Remove CheckedUnsafePtr<WorkerPrivate> in AutoSyncLoopHolder with a StrongWorkerRef.
There is no shutdown callback for AutoSyncLoopHolder::mWorkerRef since Worker's shutdown should be blocked until the created syncLoop is destroyed. Stopping the created syncLoop in the WorkerRef shutdown callback will cause memory leaking which resource releasing should be done during the execution of the syncLoop.
Remove WorkerPrivate* in AutoPushEventLoopGlobal with GetCurrentThreadWorkerPrivate().
AutoPushEventLoopGlobal is an RAII class that runs on the Worker thread. It is supposed to get a valid WorkerPrivate through GetCurrentThreadWorkerPrivate().
Depends on D211843
Differential Revision: https://phabricator.services.mozilla.com/D212556
Atomics.wait prevent WorkerDebuggerRunnable's from running by blocking the event loop.
While dispatching these runnables, also spawn a short timer which would interrupt the worker
and tentatively try to drain the debugger queue and resume any debugger runnable which may be blocked.
Differential Revision: https://phabricator.services.mozilla.com/D194081
WorkerRunnable no longer keeps a raw pointer(mWorkerPrivate) for the associated WorkerPrivate in this patch.
Removing the WorkerRunnable::mWorkerPrivate needs to fix the following problems.
1. Thread assertions in WorkerRunnable::Dispatch()
To fix this problem, the associated WorkerPrivate is as a parameter and passed to WorkerRunnable::Dispatch() for the dispatching thread assertions. This associated WorkerPrivate is also propagated to PreDispatch() and PostDispatch() for the children classes of WorkerRunnable()
2. Get the associated WorkerPrivate in WorkerRunnable::Run() for environment setup(GlobabObject, JSContext setting for the runnable)
- For WorkerThreadRunnable
Since WorkerThreadRunnable is supposed to run on the worker thread, it does not need to keep a raw pointer to WorkerPrivate as its class member. GetCurrentThreadWorkerPrivate() should always get the correct WorkerPrivate for WorkerThreadRunnable.
- For WorkerParentThreadRunnable
WorkerParentRef is introduced to keep a RefPtr<WorkerPrivate> for WorkerParentThreadRunnable instead of using a raw pointer.
Checking the associated WorkerPrivate existence by WorkerParentRef at the beginning of WorkerParentThreadRunnable::Run(). If the Worker has already shut down, WorkerParentThreadRunnable cannot do anything with the associated WorkerPrivate, so WorkerParentThreadRunnable::Run() will return NS_OK directly but with a warning.
The associated WorkerPrivate is also passed into WorkerRun(), PreRun(), and PostRun(), so the majority of implementations of child classes of WorkerRunnable do not need to be changed.
If there are any cases in which the child classes of WorkerThreadRunnable/WorkerParentThreadRunnable want to keep the associated WorkerPrivate, they should use WorkerRefs instead of raw pointers.
Depends on D205679
Differential Revision: https://phabricator.services.mozilla.com/D207039
In this patch, WorkerParentThreadRunnable is extracted from WorkerThreadRunnable for runnable on the parent thread.
WorkerParentControlRunnable and WorkerParentDebuggeeRunnable are also created for control runnable and debuggee runnable on the parent thread.
Instead of using WorkerRunnable::Target to indicate the thread target, inheriting WorkerThreadRunnable or WorkerParentThreadRunnable to point out that this runnable should run on the worker thread or on the parent thread. So WorkerRunnable::Target is removed in this patch.
This patch also move the dispatching logic into WorkerPrivate to simplify WorkerRunnable::DispatchInternal()'s implementation.
Depends on D205178
Differential Revision: https://phabricator.services.mozilla.com/D205679
Atomics.wait prevent WorkerDebuggerRunnable's from running by blocking the event loop.
While dispatching these runnables, also spawn a short timer which would interrupt the worker
and tentatively try to drain the debugger queue and resume any debugger runnable which may be blocked.
Differential Revision: https://phabricator.services.mozilla.com/D194081
After this patch, the Worker can be GCed while it is idle for events.
I want to point out the difference from the BusyCount implementation.
Compared to the BusyCount implementation, BusyCount implementation allows the Worker to be GCed during WorkerRunnable execution iff the WorkeRunnable does not modify BusyCount.
Differential Revision: https://phabricator.services.mozilla.com/D194333
This patch does:
- use our common `Create` pattern also here to move some complexity out of the constructor and improve the error handling.
- give each strong worker ref a unique name for better diagnostics.
- add a `TryShutdown` to the life-cycle worker ref, presumably this may help if the worker dies before any DispatchLoadScript(s) has been called.
Differential Revision: https://phabricator.services.mozilla.com/D192936
To allow workers to know the OverriddenFingerprintingSettings,
we populate the value to the worker loadInfo and worker private from
the document.
For service workers, we use the partitionKey in its principal to get
the OverriddenFingerprintingSettings of the given service worker.
Differential Revision: https://phabricator.services.mozilla.com/D185014
This probably should have been done earlier, but became obvious with uses of Document::HasStorageAccessPermissionGrated in this stack.
Differential Revision: https://phabricator.services.mozilla.com/D184825
This probably should have been done earlier, but became obvious with uses of Document::HasStorageAccessPermissionGrated in this stack.
Differential Revision: https://phabricator.services.mozilla.com/D184825
