This function is needed for people whose needs don't map cleanly to
`NS_DispatchToBackgroundThread`, usually because they're using the event
target to do thread consistency checks. Once we have this function, we
can start converting singleton threads/thread pools that want to use
functionality like the above.
Differential Revision: https://phabricator.services.mozilla.com/D47454
--HG--
extra : moz-landing-system : lando
Eventually, we're going to want to hand out an `nsIEventTarget*` to people
wanting to dispatch to background threads, but for whatever reason not
wanting to use the `NS_DispatchToBackgroundThread` API (probably because
they want to verify correctness by checking that certain methods are, in
fact, running on the background event target). And because we're going to
want to have some sort of division between CPU-bound and IO-bound tasks, we
can't just hand out references to a single thread pool. We need some sort
of intermediate object for both of these goals, and that is what the added
`BackgroundEventTarget` class is.
Differential Revision: https://phabricator.services.mozilla.com/D47343
--HG--
extra : moz-landing-system : lando
It's fairly common for clients to hold a pointer to some private thread
and then inquire about `IsOnCurrentThread` in debug checks. As we
migrate these private threads into some `nsIEventTarget` implementation
that might be running on thread pools, we need to ensure that those
`IsOnCurrentThread` continues to be relatively cheap. The current
implementation for thread pools is not particularly efficient.
The inefficiency comes from having to iterate over all the threads in
the pool. But there's no need to do this; we can just have each thread
set a particular thread-local variable to the thread pool it's running
on, and check the value of that thread-local variable instead.
Differential Revision: https://phabricator.services.mozilla.com/D47139
--HG--
extra : moz-landing-system : lando
We have a number of people starting up singleton threads for the sole
purpose of running a single runnable on them. These consumers often
leave the thread running until some point close to shutdown, or they
never shut it down at all. Let's add a helper function to do the thing
they actually want to do, and then we can modify the implementation of
that function as necessary as we merge singleton threads (and even
thread pools) together.
Differential Revision: https://phabricator.services.mozilla.com/D46997
--HG--
extra : moz-landing-system : lando
To remove the blocking inside nsThread::Init, two things needed
to happen:
- Switch the ThreadInitData value passed as the argument for
ThreadFunc to a heap allocation, so that it can outlive the call
to nsThread::Init.
- Initialize mThread and mEventTarget->mThread to the return
value of PR_CreateThread, so that to the callers, checks which
depend on these values being set can continue to function.
Differential Revision: https://phabricator.services.mozilla.com/D41248
--HG--
extra : moz-landing-system : lando
GetCurrentPhysicalThread and GetCurrentVirtualThread are, in practice,
identical, as the TLS override that GetCurrentVirtualThread depends on
is never actually set. This simply removes that and renames some things/
deletes some comments.
Differential Revision: https://phabricator.services.mozilla.com/D41247
--HG--
extra : moz-landing-system : lando
This is to get initial feedback/review.
PIdleScheduler.ipdl has the documentation about the basic architecture.
(v15)
Differential Revision: https://phabricator.services.mozilla.com/D45162
--HG--
extra : moz-landing-system : lando
Similar to MozPromise::FromGeckoResult.
Allows to create a MozPromise that will be resolved/rejected when the JS promise does the same.
It would be nice to be able to chain the two promise types, but it would be an additional effort.
MozPromise::FromDomPromise is limited to primitive types only and the reject value type must be nsresult.
Differential Revision: https://phabricator.services.mozilla.com/D46017
--HG--
extra : moz-landing-system : lando
This is to get initial feedback/review.
PIdleScheduler.ipdl has the documentation about the basic architecture.
(v15)
Differential Revision: https://phabricator.services.mozilla.com/D45162
--HG--
extra : moz-landing-system : lando
Similar to MozPromise::FromGeckoResult.
Allows to create a MozPromise that will be resolved/rejected when the JS promise does the same.
It would be nice to be able to chain the two promise types, but it would be an additional effort.
MozPromise::FromDomPromise is limited to primitive types only and the reject value type must be nsresult.
Differential Revision: https://phabricator.services.mozilla.com/D46017
--HG--
extra : moz-landing-system : lando
This is to get initial feedback/review.
PIdleScheduler.ipdl has the documentation about the basic architecture.
(v15)
Differential Revision: https://phabricator.services.mozilla.com/D45162
--HG--
extra : moz-landing-system : lando
EXIT_FAILURE is 'implementation defined' but can be defined to be 1.
In our case, pingsender exits with EXIT_FAILURE but nsIProcess wasn't
reporting it as failure because it thought failures were always negative.
Differential Revision: https://phabricator.services.mozilla.com/D45038
--HG--
extra : moz-landing-system : lando
EXIT_FAILURE is 'implementation defined' but can be defined to be 1.
In our case, pingsender exits with EXIT_FAILURE but nsIProcess wasn't
reporting it as failure because it thought failures were always negative.
Differential Revision: https://phabricator.services.mozilla.com/D45038
--HG--
extra : moz-landing-system : lando
EXIT_FAILURE is 'implementation defined' but can be defined to be 1.
In our case, pingsender exits with EXIT_FAILURE but nsIProcess wasn't
reporting it as failure because it thought failures were always negative.
Differential Revision: https://phabricator.services.mozilla.com/D45038
--HG--
extra : moz-landing-system : lando
All calls to `profiler_add_marker()` (outside of the profilers code) are
now replaced by either:
- `PROFILER_ADD_MARKER(name, categoryPair)`
- `PROFILER_ADD_MARKER_WITH_PAYLOAD(name, categoryPair, TypeOfMarkerPayload,
(payload, ..., arguments))`
This makes all calls consistent, and they won't need to prefix the category pair
with `JS::ProfilingCategoryPair::`.
Also it will make it easier to add (and later remove) internal-profiling
instrumentation (bug 1576550), and to replace heap-allocated payloads with
stack-allocated ones (bug 1576555).
Differential Revision: https://phabricator.services.mozilla.com/D43588
--HG--
extra : moz-landing-system : lando
We always define it to the same thing, and we're inconsistent in whether
we use `CPP_THROW_NEW` or `throw()`, so we might as well just use the
standard C++ thing and get rid of some baggage.
Differential Revision: https://phabricator.services.mozilla.com/D40425
--HG--
extra : moz-landing-system : lando
None of the StringTable implementations were freeing their strdup'd
strings, either.
Differential Revision: https://phabricator.services.mozilla.com/D40757
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
I'd like to rely on always getting a stop event when the system recovers from a memory pressure situation. AIUI this already happens on Android platforms but not on Windows. This adds the stop event for Windows.
Differential Revision: https://phabricator.services.mozilla.com/D35679
The approach isn't perhaps super elegant, but it is a small and simple tweak.
Differential Revision: https://phabricator.services.mozilla.com/D34923
--HG--
extra : moz-landing-system : lando
This patch takes the approach to count up to 100 wakeups and reports then time it took for that period. Regression in wakeups could
show up as decreased mean or median time.
Differential Revision: https://phabricator.services.mozilla.com/D32543
--HG--
extra : moz-landing-system : lando
RecordedTextureData records TextureData calls for play back in the GPU process.
CanvasChild and CanvasParent set up the recorder and translator.
They also help to manage the starting of translation and co-ordinating the
translation with the frame transactions.
This patch also includes other changes to wire up recording and playback.
