Introduces SUPPORTS_SHUTDOWN_TASKS and SUPPORTS_SHUTDOWN_TASK_DISPATCH flags.
This just wires the function through all event targets without ever being used.
Differential Revision: https://phabricator.services.mozilla.com/D272150
When nsThreadPool::PutEvent() fails to create a new thread, the behavior
should depend on whether the pool already has existing threads:
1. If the pool is empty (mThreads.Count() == 0):
- This is a fatal condition because there are no threads available to
process the queued event
- Crash with MOZ_CRASH to make this failure explicit and debuggable
2. If the pool is not empty:
- The existing threads can still handle the queued event
- Return NS_OK to allow the caller to continue normally
- This provides graceful degradation when thread creation fails but
the pool can still function
Differential Revision: https://phabricator.services.mozilla.com/D278215
Change nsThreadPool::PutEvent() to use MOZ_CRASH() instead of returning
NS_ERROR_UNEXPECTED when NS_NewNamedThread() fails to create a new thread.
Differential Revision: https://phabricator.services.mozilla.com/D278215
This avoids the small overhead and potential for bugs from the previous
approach of assuming all `const char*` arguments passed to `nsITimer`
initializers are string literals, by instead requiring the argument to be a
`const nsACString&`. This involves changing all callsites to pass a `""_ns`
string literal down instead of a bare string literal.
It appears that while there were currently no buggy callers which
would've provided a dynamic string, there was at least one piece of code
(nsRepeatService::Start) which did pass down a raw char* which may be
dynamically allocated (all callers pass down `nsLiteralCString` so we're
actually OK here right now, but this was a footgun).
Differential Revision: https://phabricator.services.mozilla.com/D261032
This reverts commit 8c929cc018.
Revert "Bug 1979013 - Part 2: Require nsITimer API callers to provide a nsACString, r=xpcom-reviewers,media-playback-reviewers,webrtc-reviewers,profiler-reviewers,dom-storage-reviewers,toolkit-telemetry-reviewers,firefox-style-system-reviewers,mstange,emz,bwc,janv,emilio,padenot"
This reverts commit e01c0a6a32.
Revert "Bug 1979013 - Part 1: Eagerly fetch name for timer callbacks, r=xpcom-reviewers,mccr8"
This reverts commit 9f8e73c163.
This avoids the small overhead and potential for bugs from the previous
approach of assuming all `const char*` arguments passed to `nsITimer`
initializers are string literals, by instead requiring the argument to be a
`const nsACString&`. This involves changing all callsites to pass a `""_ns`
string literal down instead of a bare string literal.
It appears that while there were currently no buggy callers which
would've provided a dynamic string, there was at least one piece of code
(nsRepeatService::Start) which did pass down a raw char* which may be
dynamically allocated (all callers pass down `nsLiteralCString` so we're
actually OK here right now, but this was a footgun).
Differential Revision: https://phabricator.services.mozilla.com/D261032
Have idleThreadGraceTimeout and idleThreadMaximumTimeout instead of just idleThreadTimeout.
Clarify that idleThreadMaximumTimeout is only affecting allowed idle threads.
Make idle threads end only after at minimum idleThreadGraceTimeout even if they are in excess.
Remove the idleThreadTimeoutRegressive setting.
Introduce a "most recently used" priority for notifying idle threads to
avoid excessive round-robin through all available idle threads.
The management of the linked list has constant time, adding thus only
minimal overhead wrt to the previous wasIdle flags we had.
As a side effect (and coming from the investigations in bug 1891732) to
some extent this can help to improve the "logical thread affinity",
together with trying to keep events dispatched with NS_DISPATCH_AT_END
on the dispatching thread as much as possible, which should help
TaskQueue a lot with affinity.
Differential Revision: https://phabricator.services.mozilla.com/D209884
It looks like this was an oversight in bug 1155059, that in one place an
already_AddRefed does not get converted to a RefPtr.
Differential Revision: https://phabricator.services.mozilla.com/D197374
It looks like this was an oversight in bug 1276549, that in one place an
already_AddRefed does not get converted to a RefPtr.
Differential Revision: https://phabricator.services.mozilla.com/D197374
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
This flag is not supported by most event targets and can have unexpected
side effects (namely spinning a nested event loop). All consumers have
been replaced with a new function which is more explicit about this side
effect.
Differential Revision: https://phabricator.services.mozilla.com/D173985
This will be used to deprioritize whole thread pools. The concept works as such:
- Set a thread pool's priority at any time
- Each thread will ensure their priority mirrors the parent pool's priority when it is finished processing events.
I chose to have threads only set themselves to the background when they finish processing events because an event dispatched at an expected priority should be completed at said priority. This ensures that any event dispatch that may expect normal priority (i.e. not operating in the background) has a chance to run at the established priority.
This patch enrolls the background IO to low priority on its creation. It also includes the MacOS implementation of the thread priorities, which utilizes mac's QoS service. According to MacOS's QoS structure, main threads operate at `user-interactive` and offthread work is done at a `default` state, meaning that the OS decides how to set the thread's priority somewhere between `utility` and `user-interactive`. When a thread is put in the background, it must be manually raised back to the expected priority, which means most threads must set themselves to `default` again and the main thread must set itself to `user-interactive`. I demonstrated this in the `nsThread` implementation by checking for the main thread and if this task is running on the main thread somehow, then we use the correct setting.
Rather than having the thread pools dispatch their own deprioritization tasks, I've decided to make this the job of the nsThread. In following bugs we will put entire processes' nsThreads in the background, which will require more use of the new nsThread codepaths.
This behavior is currently restricted to nightly only. On platforms with no implementation, nothing will change.
Differential Revision: https://phabricator.services.mozilla.com/D146534
This was always being tracked internlly to implement
nsThreadPool::IsOnCurrentThread, however this patch exposes the getter
publicly.
This will be used to assert if GetCurrentSerialEventTarget() is called from a
threadpool thread without a TaskQueue in the next part.
Differential Revision: https://phabricator.services.mozilla.com/D166603
This was always being tracked internlly to implement
nsThreadPool::IsOnCurrentThread, however this patch exposes the getter
publicly.
This will be used to assert if GetCurrentSerialEventTarget() is called from a
threadpool thread without a TaskQueue in the next part.
Differential Revision: https://phabricator.services.mozilla.com/D166603
There are only 3 places where nsMemory.h is still needed (image/RasterImage.cpp,
gfx/thebes/gfxFT2FontList.cpp, and nsMemory.cpp). Remove the rest.
Differential Revision: https://phabricator.services.mozilla.com/D158213
This change introduces a new interface, nsIThreadShutdown, which is used
to handle the relevant state for communicating thread shutdown state
between the joining and terminating threads. This type is now returned
from `nsIThread::AsyncShutdown` and can be used to register callbacks
for when thread shutdown is complete, as well as cancel shutdown
entirely, leading to the underlying PRThread never being joined using
PR_JoinThread. This leaking limitation may be avoidable if support for
detaching PRThreads is added to NSPR, or nsThread switches to a more
feature-complete threading API.
This patch also uses the new interface to rework nsThreadPool's Shutdown
and ShutdownWithTimeout methods to avoid poking at nsThread internals
and instead use the publicly facing methods. This allows us to start
async shutdown for all threads and spin the event loop until they all
complete, or a timeout timer fires.
Differential Revision: https://phabricator.services.mozilla.com/D136045
These changes were necessary for me to build successfully with this in my
mozconfig:
ac_add_options --enable-debug
ac_add_options --disable-unified-build
ac_add_options --enable-profiling
While I'm here, I removed a duplicate include in InputTaskManager.h, and made
nsThreadPool.cpp include its own header first, to match Gecko common practice.
Differential Revision: https://phabricator.services.mozilla.com/D127503
There are no code changes, only #include changes.
It was a fairly mechanical process: Search for all "AUTO_PROFILER_LABEL", and in each file, if only labels are used, convert "GeckoProfiler.h" into "ProfilerLabels.h" (or just add that last one where needed).
In some files, there were also some marker calls but no other profiler-related calls, in these cases "GeckoProfiler.h" was replaced with both "ProfilerLabels.h" and "ProfilerMarkers.h", which still helps in reducing the use of the all-encompassing "GeckoProfiler.h".
Differential Revision: https://phabricator.services.mozilla.com/D104588
serge-sans-paille