- Fixes a data race where the member variable is being written to by
EnsurePerformanceCounter on the worker thread while being read on a separate
thread (via Worker.postMessage).
- Apply some pointer guildelines to the member variable getters.
- Constify some things that should be const.
Differential Revision: https://phabricator.services.mozilla.com/D82475
We want it to returning the actual nsThread if that's where the MessageLoop would dispatch its tasks; otherwise return the MessageLoop's EventTarget
Depends on D80357
Differential Revision: https://phabricator.services.mozilla.com/D80811
We want it to returning the actual nsThread if that's where the MessageLoop would dispatch its tasks; otherwise return the MessageLoop's EventTarget
Depends on D80357
Differential Revision: https://phabricator.services.mozilla.com/D80811
Apparently I added these in the initial commit for RecursiveMutex. I'm
not quite sure what I was thinking, but we don't need them for the
RecursiveMutex itself. (We have them on the corresponding `*Auto*Lock`
classes, which are also `MOZ_RAII`.)
Differential Revision: https://phabricator.services.mozilla.com/D81345
This will allow to remove AbstractThread::Current() as GetCurrentSerialEventTarget TLS value will be set whenever a task dispatched on the XPCOMThreadWrapper is run.
Differential Revision: https://phabricator.services.mozilla.com/D80355
Before P1, GetCurrentThreadSerialEventTarget would have always returned the same data as NS_GetCurrentThread, making the comment incorrect Now it will properly return the running TaskQueue if any.
This change of name more clearly exposes what they are doing, as we aren't always dealing with threads directly; but a nsISerialEventTarget
Differential Revision: https://phabricator.services.mozilla.com/D80354
In the future, we may want to extend GetCurrentThreadSerialEventTarget to return the actual nsISerialEventTarget used to dispatch the task.
Differential Revision: https://phabricator.services.mozilla.com/D80353
When TaskQueue was first conceived; it was only used with AbstractThreads and with tail dispatch.
By default, AbstractThread::Dispatch dropped the flags , as it was dispatching all tasks via the tail dispatcher.
It was an oversight, there's no use-case where we wouldn't want the dispatch flags to be carried forward.
It also simplifies the code and TaskQueue's use.
Depends on D80351
Differential Revision: https://phabricator.services.mozilla.com/D80352
We have a clang-plugin check that wants to prefer `SprintfLiteral` over `snprintf`, but for some reason this wasn't caught before clang-11. I _think_ it has to do with previous versions not being able to see that `buflen` was constant, but I'm not really sure.
Differential Revision: https://phabricator.services.mozilla.com/D80021
This removes variants of "blacklist" from the xpcom directory. The preference name "network.file.path_blacklist" is left in place and will need a more thorough plan for removal. Instances of `MOZ_ASAN_BLACKLIST` remain as well and should be replaced in a larger modifcation of the `#define` in the mfbt component.
Differential Revision: https://phabricator.services.mozilla.com/D80098
When chaining a MozPromise set to be dispatched via the direct task queue (or synchronous), it makes sense for the chained promise to be dispatched in the same fashion.
All MozPromises generated by the IPC bindings are set to use the direct task queue in order to prevent the then runnable to run out of order with other IPC tasks.
We want to preserve that task ordering by default.
Differential Revision: https://phabricator.services.mozilla.com/D78178
This prevent being able to assert in the AutoTaskDispatcher that we are using it from the right thread/taskqueue as the SimpleTaskQueue object isn't thread-safe.
We want to assert that all nsIDirectTaskDispatcher methods are only ever accessed on the underlying thread. To do so require that the scope of AutoTaskDispatcher to terminate prior the AutoTaskGuard one.
Differential Revision: https://phabricator.services.mozilla.com/D79096
We extract the dealing of direct tasks from the TailDispatcher object and move into to the existing nsThread and TaskQueue classes.
TaskQueue is made to work with do_QueryInterface.
We continue accessing the direct tasks dispatcher via the TailDispatcher for now, which itself will forward the dealing of such tasks to the underlying thread.
Differential Revision: https://phabricator.services.mozilla.com/D79093
When chaining a MozPromise set to be dispatched via the direct task queue (or synchronous), it makes sense for the chained promise to be dispatched in the same fashion.
All MozPromises generated by the IPC bindings are set to use the direct task queue in order to prevent the then runnable to run out of order with other IPC tasks.
We want to preserve that task ordering by default.
Differential Revision: https://phabricator.services.mozilla.com/D78178
