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
When performing the last GC, remaining state watchers would dispatch direct tasks ; this was exposed with P3. Ensure this never happens.
Differential Revision: https://phabricator.services.mozilla.com/D75499
During the last cycle collection, state watchers may attempt to dispatch tasks to the current AbstractThread, so we can't clear the TLS entry until that step has completed.
We want the object to be deleted last; ordering in call to ClearOnShutdown() can't guarantee it.
Differential Revision: https://phabricator.services.mozilla.com/D75498
Gecko Idle detection relies heavily on RefreshDriver. GC/CC scheduling, including when to run GC or CC slices, and the length of the slices, is mostly based on idle time. As WebXR isn't using normal RefreshDriver, the content process thinks it's idle and GC and CC get basically up to 50 ms slices.
Not having WebXR idle detection is causing stutter frames during immersive presentation. This patch implements idle deadline hint and sets the correct GC slices budgets during WebXR presentation.
Differential Revision: https://phabricator.services.mozilla.com/D74426
This wraps the current thread such that a call to Dispatch will be done as direct task dispatch instead so that the task will be run in the current event loop.
This allows for have similar (but not identical to) the microtask semantics of JS promises
Differential Revision: https://phabricator.services.mozilla.com/D69995
If set, the callback will be dispatched via a direct task.
Direct tasks are run via the current thread's tail dispatcher.
This mechanism is only available if both the caller and the target are on the same thread and an AbstractThread is available
Differential Revision: https://phabricator.services.mozilla.com/D71592
already_AddRefed destructor assert that it's nullptr.
DelayedDispatch check that the value passed isn't 0 and return an error code, leaving the already_AddRefed untouched.
Differential Revision: https://phabricator.services.mozilla.com/D73821
already_AddRefed destructor assert that it's nullptr.
DelayedDispatch check that the value passed isn't 0 and return an error code, leaving the already_AddRefed untouched.
Differential Revision: https://phabricator.services.mozilla.com/D73821
already_AddRefed destructor assert that it's nullptr.
DelayedDispatch check that the value passed isn't 0 and return an error code, leaving the already_AddRefed untouched.
Differential Revision: https://phabricator.services.mozilla.com/D73821
In non-DEBUG builds, `OffTheBooksCondVar::Wait` has `AUTO_PROFILER_THREAD_SLEEP`, but it's not in DEBUG builds.
`profiler_thread_sleep` does a `MOZ_ASSERT(mSleep == AWAKE)` in DEBUG builds, so the double call that happens in non-DEBUG wouldn't trigger the assertion!
This patch adds `AUTO_PROFILER_THREAD_SLEEP` in DEBUG `OffTheBooksCondVar::Wait`, to catch more misuses during development.
Depends on D72851
Differential Revision: https://phabricator.services.mozilla.com/D72852
CondVar already calls `AUTO_PROFILER_THREAD_SLEEP`, which shouldn't be called recursively.
mozilla::Monitor also uses CondVar, so it shouldn't be surrounded by `AUTO_PROFILER_THREAD_SLEEP` either.
Depends on D72850
Differential Revision: https://phabricator.services.mozilla.com/D72851
This is in preparation for running the tail dispatcher off
nsIThreadObserver callbacks, which only work during regular
event processing.
Differential Revision: https://phabricator.services.mozilla.com/D72264
This is how it used to be, before the Quantum DOM stuff. We use
nsIThreadInternal because that supports thread observers, which we
leverage in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D71709
It was required once upon a time to be able to use MozPromise on Workers.
Today a MozPromise work with nsISerialEventTarget and no longer rely on this. It can go.
Differential Revision: https://phabricator.services.mozilla.com/D71442
AutoEnter was an attempt around a race between AbstractThread and MessageLoopAbstractThreadWrap that would cause AbstractThread::GetCurrent() to return an incorrect value. MessageLoopAbstractThreadWrapper is no more and as such AutoEnter is no longer required.
Differential Revision: https://phabricator.services.mozilla.com/D71279
prior bug 1364821, AbstractThread::GetCurrent() would always return AbstractThread::MainThread() when called from the main thread.
After this change, we had to run within an AutoEnter scope.
A hidden side effect of this change was that under most cases AbstractThread::MainThread::Dispatch() would no longer use the tail dispatcher to dispatch a task.
It can be safely assume that whenever you're on the main thread, the equivalent AbstractThread is usable.
In the next commit, we will be removing AutoEnter entirely.
Differential Revision: https://phabricator.services.mozilla.com/D71148
One could possibly make larger changes to make the setup less error prone, but hopefully we'll
replace this code with the new scheduler relatively soon.
And the assertion there should still enforce correct behavior.
Differential Revision: https://phabricator.services.mozilla.com/D69988
--HG--
extra : moz-landing-system : lando
This commit removes `test_fix_stack_using_bpsyms.py`. That test can't easily be
modified to work with `fix_stacks.py` because it relies on internal
implementation details of `fix_stack_using_bpsym.py`. The unit testing done in
the `fix-stacks` repo provides test coverage that is as good or better.
Differential Revision: https://phabricator.services.mozilla.com/D66924
--HG--
extra : moz-landing-system : lando
Also moves `nsThreadShutdownContext` to `nsThread.h` so it can be used by `nsThreadPool`.
Differential Revision: https://phabricator.services.mozilla.com/D69657
--HG--
extra : moz-landing-system : lando
TabGroup never really made any difference in which thread something go
dispatched to. This was the intended use, but development of TabGroups
with abstract main threads never made it that far. The good thing is
that thish makes it safe to also remove to the SystemGroup and instead
switch all SystemGroup dispatches to dispatches to main thread.
Timers for setTimeout and workers were the sole users of wrapped and
throttled event targets, that those throttled queues have been moved
to the BrowsingContextGroup and are now accessed explicitly.
The SchedulerEventTarget has been removed, since there are no longer a
separate event target for every TaskCategory. Instead a
LabellingEventTarget has been added to DocGroup to handle the case
where an event is dispatched do DocGroup or when an AbstractThread is
created using a DocGroup. This means that we'll actually label more
events correctly with the DocGroup that they belong to.
DocGroups have also been moved to BrowsingContextGroup.
Depends on D67636
Differential Revision: https://phabricator.services.mozilla.com/D65936
--HG--
extra : moz-landing-system : lando
To be able to remove SystemGroup, NS_ReleaseOnMainThreadSystemGroup
needs to have its dependency on SystemGroup removed. Since all
releases using SystemGroup would've released on the main thread anyway
we can safely replace NS_ReleaseOnMainThreadSystemGroup with
NS_ReleaseOnMainThread.
Depends on D64390
Differential Revision: https://phabricator.services.mozilla.com/D67631
--HG--
extra : moz-landing-system : lando
Also adds missing includes in some files, these were previously only transivitely
included through mozilla/TypeTraits.h.
Differential Revision: https://phabricator.services.mozilla.com/D68561
--HG--
extra : moz-landing-system : lando
Also move MOZ_MUST_USE before function declarations' specifiers and return type. While clang and gcc's __attribute__((warn_unused_result)) can appear before, between, or after function specifiers and return types, the [[nodiscard]] attribute must precede the function specifiers.
Also remove MOZ_MUST_USE from nsIMemoryReporter's function pointer typedefs. [[nodiscard]] is an attribute of a function's declaration, not the function's type, and thus can't be applied to function pointers or lambdas.
Differential Revision: https://phabricator.services.mozilla.com/D68138
--HG--
extra : moz-landing-system : lando
This commit moves `NS_CreateBackgroundTaskQueue` into an `extern "C"`
block, adds a `create_background_task_queue` function to `moz_task`,
and makes it possible to dispatch Rust `TaskRunnable`s to any event
target, instead of just an `nsIThread`.
Differential Revision: https://phabricator.services.mozilla.com/D66700
--HG--
extra : moz-landing-system : lando
The BindingCallContext tracks what method the conversion is for, and the source
description is how the primitive is involved in that method (e.g. "argument 5").
Differential Revision: https://phabricator.services.mozilla.com/D64887
--HG--
extra : moz-landing-system : lando
The BindingCallContext tracks what method the conversion is for, and the source
description is how the primitive is involved in that method (e.g. "argument 5").
Differential Revision: https://phabricator.services.mozilla.com/D64887
--HG--
extra : moz-landing-system : lando
Idle runnables do weird things involving unlocking the event queue mutex while
looking for runnables, such that queueing one from off the main thread might
cause it to basically never run if it gets queued during one of those
temporary-unlock periods.
Differential Revision: https://phabricator.services.mozilla.com/D65019
--HG--
extra : moz-landing-system : lando
We want to be able to send IPC messages from the translation in the parent. So
the simplest thing it move the top level actor parts of CanvasParent into
CanvasTranslator.
This patch also moves the canvas thread management parts out into a new
CanvasThreadHolder class and hopefully makes the lifecycle management of these
much more robust. This includes the use of a TaskQueue per CanvasTranslator to
manage serial processing on the canvas workers, instead of a boolean.
Differential Revision: https://phabricator.services.mozilla.com/D60887
--HG--
rename : gfx/layers/ipc/CanvasParent.cpp => gfx/layers/ipc/CanvasThread.cpp
rename : gfx/layers/ipc/CanvasParent.h => gfx/layers/ipc/CanvasThread.h
rename : gfx/layers/CanvasTranslator.cpp => gfx/layers/ipc/CanvasTranslator.cpp
rename : gfx/layers/CanvasTranslator.h => gfx/layers/ipc/CanvasTranslator.h
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
The patch removes the tad odd interleave behavior from the main thread and makes RefreshDriver to give
at least a tiny bit time for non-high priority tasks.
Given the recent change to have similar block-until behavior in child and parent process, this should work
consistently in all the processes.
Differential Revision: https://phabricator.services.mozilla.com/D63098
--HG--
extra : moz-landing-system : lando
This change is a little gross, because we don't totally control where
the statically initialized instances of `RWLock` live, due to its uses
in third-party libraries.
Differential Revision: https://phabricator.services.mozilla.com/D62936
--HG--
extra : moz-landing-system : lando
Without this we can run into stack overflows caused by unoptimized Rust
code.
Differential Revision: https://phabricator.services.mozilla.com/D62476
--HG--
extra : moz-landing-system : lando
Gets rid of `NS_NewThread`. Where it was used in testing, I gave the new named threads names relevant to their tests.
Differential Revision: https://phabricator.services.mozilla.com/D62475
--HG--
extra : source : 541b98270c9985c5bd3569ff3ff8bc6c3d3c650a
Gets rid of `NS_NewThread`. Where it was used in testing, I gave the new named threads names relevant to their tests.
Differential Revision: https://phabricator.services.mozilla.com/D62475
--HG--
extra : moz-landing-system : lando
This was done by:
This was done by applying:
```
diff --git a/python/mozbuild/mozbuild/code-analysis/mach_commands.py b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
index 789affde7bbf..fe33c4c7d4d1 100644
--- a/python/mozbuild/mozbuild/code-analysis/mach_commands.py
+++ b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
@@ -2007,7 +2007,7 @@ class StaticAnalysis(MachCommandBase):
from subprocess import Popen, PIPE, check_output, CalledProcessError
diff_process = Popen(self._get_clang_format_diff_command(commit), stdout=PIPE)
- args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format]
+ args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format, '-sort-includes']
if not output_file:
args.append("-i")
```
Then running `./mach clang-format -c <commit-hash>`
Then undoing that patch.
Then running check_spidermonkey_style.py --fixup
Then running `./mach clang-format`
I had to fix four things:
* I needed to move <utility> back down in GuardObjects.h because I was hitting
obscure problems with our system include wrappers like this:
0:03.94 /usr/include/stdlib.h:550:14: error: exception specification in declaration does not match previous declaration
0:03.94 extern void *realloc (void *__ptr, size_t __size)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/malloc_decls.h:53:1: note: previous declaration is here
0:03.94 MALLOC_DECL(realloc, void*, void*, size_t)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozilla/mozalloc.h:22:32: note: expanded from macro 'MALLOC_DECL'
0:03.94 MOZ_MEMORY_API return_type name##_impl(__VA_ARGS__);
0:03.94 ^
0:03.94 <scratch space>:178:1: note: expanded from here
0:03.94 realloc_impl
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozmemory_wrap.h:142:41: note: expanded from macro 'realloc_impl'
0:03.94 #define realloc_impl mozmem_malloc_impl(realloc)
Which I really didn't feel like digging into.
* I had to restore the order of TrustOverrideUtils.h and related files in nss
because the .inc files depend on TrustOverrideUtils.h being included earlier.
* I had to add a missing include to RollingNumber.h
* Also had to partially restore include order in JsepSessionImpl.cpp to avoid
some -WError issues due to some static inline functions being defined in a
header but not used in the rest of the compilation unit.
Differential Revision: https://phabricator.services.mozilla.com/D60327
--HG--
extra : moz-landing-system : lando
rg -l 'mozilla/Move.h' | xargs sed -i 's/#include "mozilla\/Move.h"/#include <utility>/g'
Further manual fixups and cleanups to the include order incoming.
Differential Revision: https://phabricator.services.mozilla.com/D60323
--HG--
extra : moz-landing-system : lando
The idea is to use the slice-accounting setup from the performance counters for
idle tasks as well, and fix the various bugs we have when nested event loops
are involved.
The bit in nsThread::SizeOfEventQueues that counted memory for
mCurrentPerformanceCounter was wrong all along, I think: the docgroup that owns
the performance counter should account for it.
Differential Revision: https://phabricator.services.mozilla.com/D59596
--HG--
extra : moz-landing-system : lando
Jean-Yves Avenard
Honza Bambas
Brindusan Cristian
Nihanth Subramanya
Nathan Froyd
Bas Schouten
David Major
Eric Rahm
Simon Giesecke
Razvan Maries
Dana Keeler
Bogdan Tara
Sylvestre Ledru
Lina Cambridge
Imanol Fernandez
Narcis Beleuzu
Mirko Brodesser
Dorel Luca
Gerald Squelart
Bobby Holley
Ciure Andrei
Olli Pettay
Nicholas Nethercote
Andreas Farre
André Bargull
Chris Peterson
Boris Zbarsky
Arthur Iakab
Andrew McCreight
Bob Owen
shindli
Jeff Muizelaar
Kristen Wright
Emilio Cobos Álvarez