The workaround is no longer necessary because NSPR has been fixed.
This allows to use PR_GetThreadName that otherwise returns an empty string.
Differential Revision: https://phabricator.services.mozilla.com/D181861
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 method always returned GetMainThreadSerialEventTarget(). This patch
switches all callers over to use that method instead.
We can't easily switch all calls to be calls to NS_GetMainThread(), as there is
no version of that method returning a bare nsIThread* instance.
I didn't introduce one, as we may want to add a lock around mMainThread in the
future, which would require removing nsThreadManager::GetMainThreadWeak. As
this method only returns nsISerialEventTarget, it method could remain
implemented, however, by returning a statically allocated fake event target
which forwards dispatches (and QIs to nsIThread) to the real main thread.
Differential Revision: https://phabricator.services.mozilla.com/D166608
This only changes the behaviour when called with a TaskQueue or other type
using SerialEventTargetGuard on the stack. They are being switched over as the
existing GetCurrentEventTarget method is being removed, as it is somewhat
confusing, and poorly documented.
Callers which need to get the current thread even when on a threadpool or
behind a TaskQueue were switched to GetCurrentEventTarget in the previous part.
Differential Revision: https://phabricator.services.mozilla.com/D166607
These callers are depending on the existing behaviour which always returns a
thread, and does not respect custom TaskQueues. In the next part, all remaining
callers will be switched to GetCurrentSerialEventTarget.
Differential Revision: https://phabricator.services.mozilla.com/D166606
We aren't likely to try to make these changes any time soon, so cleaning out
these unnecessary methods which just return `this` will simplify things.
I was unable to find any calls to the `.eventTarget` getter in JS, which makes
sense, as the nsIThread type is only really used in JS as a wrapper around the
main thread in older code. Because of that, it has been removed as well.
Differential Revision: https://phabricator.services.mozilla.com/D166605
This will help catch issues such as the one from bug 1806751, as we will assert
earlier in the process. This also aligns better with the existing documentation
of the method (which has been updated), which suggests that the method would
assert if called on a thread pool.
Differential Revision: https://phabricator.services.mozilla.com/D166604
This method always returned GetMainThreadSerialEventTarget(). This patch
switches all callers over to use that method instead.
We can't easily switch all calls to be calls to NS_GetMainThread(), as there is
no version of that method returning a bare nsIThread* instance.
I didn't introduce one, as we may want to add a lock around mMainThread in the
future, which would require removing nsThreadManager::GetMainThreadWeak. As
this method only returns nsISerialEventTarget, it method could remain
implemented, however, by returning a statically allocated fake event target
which forwards dispatches (and QIs to nsIThread) to the real main thread.
Differential Revision: https://phabricator.services.mozilla.com/D166608
This only changes the behaviour when called with a TaskQueue or other type
using SerialEventTargetGuard on the stack. They are being switched over as the
existing GetCurrentEventTarget method is being removed, as it is somewhat
confusing, and poorly documented.
Callers which need to get the current thread even when on a threadpool or
behind a TaskQueue were switched to GetCurrentEventTarget in the previous part.
Differential Revision: https://phabricator.services.mozilla.com/D166607
These callers are depending on the existing behaviour which always returns a
thread, and does not respect custom TaskQueues. In the next part, all remaining
callers will be switched to GetCurrentSerialEventTarget.
Differential Revision: https://phabricator.services.mozilla.com/D166606
We aren't likely to try to make these changes any time soon, so cleaning out
these unnecessary methods which just return `this` will simplify things.
I was unable to find any calls to the `.eventTarget` getter in JS, which makes
sense, as the nsIThread type is only really used in JS as a wrapper around the
main thread in older code. Because of that, it has been removed as well.
Differential Revision: https://phabricator.services.mozilla.com/D166605
This will help catch issues such as the one from bug 1806751, as we will assert
earlier in the process. This also aligns better with the existing documentation
of the method (which has been updated), which suggests that the method would
assert if called on a thread pool.
Differential Revision: https://phabricator.services.mozilla.com/D166604
This code was previously incorrectly targeting the timer at the dispatching
thread. This is fortunately not an issue, as idle runnables with timeouts are
always dispatched from the main thread, however it could be an issue for future
idle runnables with timeouts dispatched from off-main-thread.
Differential Revision: https://phabricator.services.mozilla.com/D166610
This code was previously incorrectly targeting the timer at the dispatching
thread. This is fortunately not an issue, as idle runnables with timeouts are
always dispatched from the main thread, however it could be an issue for future
idle runnables with timeouts dispatched from off-main-thread.
Differential Revision: https://phabricator.services.mozilla.com/D166610
This has several implications:
* A race-condition that could manifest itself both on macOS and Linux is
removed. The race could happen if we took the lock to the thread name
mapping while another suspended thread was in the memory allocator. Taking
the lock required an allocation thus the thread acting within the exception
handler would get stuck.
* We save a few KiBs of memory per process since we don't have to keep the
thread name mapping around.
* Thread startup will be slightly faster since the first thing each new thread
did was to fill its own mapping.
Differential Revision: https://phabricator.services.mozilla.com/D139319
This patch contains changes to moz_task to improve it's support for
async execution on multiple threads. Unlike the previous executor
implementation, this new implementation reduces the amount of unsafe
code substantially by depending on the async-task crate
(https://crates.io/crates/async-task) for the core task implementation.
This adds a few additional features:
* Both local (no Send bound) and non-local (with Send bound) execution support,
* Support for spawning on arbitrary nsIEventTargets or the background task pool,
* Returned Task objects from runnables which may be .await-ed on or detach()-ed,
* Support for spawning with the NS_DISPATCH_EVENT_MAY_BLOCK flag set,
* Automatic use of NS_DISPATCH_AT_END when required,
* Support for specifying the runnable priority for runnables.
There are also some correctness improvements, and exposed a better API
for dispatching normal runnable functions to background threads.
After these changes the TaskRunnable API should no longer be necessary.
It is re-implemented on top of the executor and kept in-place to avoid
rewriting all consumers.
Differential Revision: https://phabricator.services.mozilla.com/D130705
xpcom/threads/CPUUsageWatcher.cpp:43:23: error: unused variable 'kCPUCheckInterval' [-Werror,-Wunused-const-variable]
xpcom/threads/CPUUsageWatcher.cpp:109:23: error: unused variable 'kCPUCheckInterval' [-Werror,-Wunused-const-variable]
xpcom/threads/InputEventStatistics.cpp:18:5: error: use of undeclared identifier 'ClearOnShutdown'
xpcom/threads/InputTaskManager.cpp:62:9: error: use of undeclared identifier 'InputEventStatistics'
xpcom/threads/InputTaskManager.cpp:89:3: error: use of undeclared identifier 'InputEventStatistics'
xpcom/threads/InputTaskManager.cpp:105:7: error: use of undeclared identifier 'nsRefreshDriver'
xpcom/threads/InputTaskManager.cpp:124:9: error: use of undeclared identifier 'InputEventStatistics'
xpcom/threads/MainThreadIdlePeriod.cpp:29:23: error: unused variable 'kMaxTimerThreadBoundClamp' [-Werror,-Wunused-const-variable]
xpcom/threads/VsyncTaskManager.h:15:67: error: implicit instantiation of undefined template 'mozilla::StaticRefPtr<mozilla::VsyncTaskManager>'
xpcom/threads/VsyncTaskManager.h:16:52: error: no viable overloaded '='
xpcom/threads/nsMemoryPressure.cpp:61:12: error: use of undeclared identifier 'nsIObserverService'
xpcom/threads/nsMemoryPressure.cpp:61:37: error: use of undeclared identifier 'services'
xpcom/threads/nsThreadManager.cpp:422:28: error: member access into incomplete type 'mozilla::ThreadEventTarget'
xpcom/threads/nsThreadManager.cpp:661:5: error: use of undeclared identifier 'CrashReporter'
xpcom/threads/nsThreadManager.cpp:662:59: error: expected ')'
xpcom/threads/nsThreadManager.cpp:662:9: error: use of undeclared identifier 'CrashReporter'
xpcom/threads/nsThreadManager.cpp:669:7: error: use of undeclared identifier 'CrashReporter'
xpcom/threads/nsThreadManager.cpp:670:11: error: use of undeclared identifier 'CrashReporter'
xpcom/threads/nsThreadManager.cpp:670:61: error: expected ')'
xpcom/threads/nsThreadManager.cpp:672:7: error: use of undeclared identifier 'CrashReporter'
xpcom/threads/nsThreadManager.cpp:673:11: error: use of undeclared identifier 'CrashReporter'
xpcom/threads/nsThreadUtils.cpp:636:13: error: member access into incomplete type 'mozilla::Task'
Differential Revision: https://phabricator.services.mozilla.com/D127041
This causes no behavior changes in the current code because existing runnables
passed to NS_DispatchToThreadQueue() are either run on the main thread where
OnDiscard() is not called or they have only a no-op OnDiscard().
Differential Revision: https://phabricator.services.mozilla.com/D98120
Classes that inherit from DiscardableRunnable are only promising that it is OK
for Run() to be skipped, rather than promising that Cancel() is effective.
Differential Revision: https://phabricator.services.mozilla.com/D98117
Ashley Zebrowski