Remove mWorkerPrivate from WorkerMainThreadRunnable. Instead, using a ThreadSafeWorkerRef to keep Worker alive until the created syncLoop is destroyed.
In general, WorkerMainThreadRunnable::mWorkerPrivate is only used for dispatching the MainThreadStopSyncLoopRunnable back to the Worker thread. Because of the syncLoop, the Worker is supposed to be kept alive until the created syncLoop is destroyed.
RefPtr<ThreadSafeWorkerRef> WorkerMainThreadRunnable::mWorkerRef is introduced to ensure a valid WorkerPrivate during WorkerMainThreadRunnable's execution.
WorkerMainThreadRunnable::mWorkerRef is allocated just before creating a syncLoop in WorkerMainThreadRunnable::Dispatch. And released after the created syncLoop::Run() finishes.
Depends on D212556
Differential Revision: https://phabricator.services.mozilla.com/D212557
These properties were previously being checked much later, during xptcodegen,
and causing methods to be treated as noscript implicitly.
This change enforces the noscript requirements earlier when possible in
xpidl.py, to produce better errors, and adds addiitonal checks to ensure that
types which need to be builtinclass are marked as such.
This required some changes to interfaces in order to satisfy the new checks.
Differential Revision: https://phabricator.services.mozilla.com/D207804
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
This is the first step in splitting the parent thread runnable out of WorkerRunnable.
To reuse the runnable dispatching codes in Worker, we still need a base class for runnable on the worker thread and the parent thread.
In this patch, we rename the original WorkerRunnable to WorkerThreadRunnable and make WorkerRunnable to be WorkerThreadRunnable's parent class.
In the second patch, we will create WorkerParentThreadRunnable and its sub-classes, split from WorkerThreadRunnable for runnable on the Worker's parent thread.
And in the third patch, we will re-structure the content of WorkerParentThreadRunnable to remove unnecessary members.
Differential Revision: https://phabricator.services.mozilla.com/D205178
Sorry this is not a particularly easy patch to review. But it should be
mostly straight-forward.
I kept Document::Dispatch mostly for convenience, but could be
cleaned-up too / changed by SchedulerGroup::Dispatch. Similarly maybe
that can just be NS_DispatchToMainThread if we add an NS_IsMainThread
check there or something (to preserve shutdown semantics).
Differential Revision: https://phabricator.services.mozilla.com/D190450
Replace the existing callers of `JS::NewArrayBufferWithContents` with the new
`UniquePtr` alternative.
Three callers to the old `JS::NewArrayBufferWithContents` function were left
unchanged:
- `mozilla::dom::FileReader::OnLoadEndArrayBuffer()` and
`mozilla::dom::ArrayBufferBuilder::TakeArrayBuffer()` both store the data
buffer as members and therefore have a more complicated lifetime.
- `JSStructuredCloneReader::readTransferMap()` because it's not clear if the
data can be free'ed when `ArrayBuffectObject` allocation fails.
Differential Revision: https://phabricator.services.mozilla.com/D182588
Replace the existing callers of `JS::NewArrayBufferWithContents` with the new
`UniquePtr` alternative.
Three callers to the old `JS::NewArrayBufferWithContents` function were left
unchanged:
- `mozilla::dom::FileReader::OnLoadEndArrayBuffer()` and
`mozilla::dom::ArrayBufferBuilder::TakeArrayBuffer()` both store the data
buffer as members and therefore have a more complicated lifetime.
- `JSStructuredCloneReader::readTransferMap()` because it's not clear if the
data can be free'ed when `ArrayBuffectObject` allocation fails.
Differential Revision: https://phabricator.services.mozilla.com/D182588
Replace the existing callers of `JS::NewArrayBufferWithContents` with the new
`UniquePtr` alternative.
Three callers to the old `JS::NewArrayBufferWithContents` function were left
unchanged:
- `mozilla::dom::FileReader::OnLoadEndArrayBuffer()` and
`mozilla::dom::ArrayBufferBuilder::TakeArrayBuffer()` both store the data
buffer as members and therefore have a more complicated lifetime.
- `JSStructuredCloneReader::readTransferMap()` because it's not clear if the
data can be free'ed when `ArrayBuffectObject` allocation fails.
Differential Revision: https://phabricator.services.mozilla.com/D182588
