Uses IOPRIO_CLASS_BE at priority 7 (lowest best-effort) via syscall,
throttling disk access without risking starvation. This matches the
semantics of macOS IOPOL_THROTTLE and Windows THREAD_MODE_BACKGROUND_BEGIN.
Not enabled on Android because the platform seccomp filter blocks
ioprio_get/ioprio_set on at least arm32 (Bug 2035650).
Differential Revision: https://phabricator.services.mozilla.com/D296708
Uses IOPRIO_CLASS_BE at priority 7 (lowest best-effort) via syscall,
throttling disk access without risking starvation. This matches the
semantics of macOS IOPOL_THROTTLE and Windows THREAD_MODE_BACKGROUND_BEGIN.
Differential Revision: https://phabricator.services.mozilla.com/D296708
This is a large number of largely mechanical changes. When possible, the code
was called to directly call `.get()` instead, performing the assertions
manually. In many places PromiseFlatCString() calls were added to dynamically
copy the strings into null terminated buffers if the string was not null
terminated.
Differential Revision: https://phabricator.services.mozilla.com/D286158
The PrioritizableRunnable asserted that it runs on the main thread.
In order to prioritize events on the socket thread we also allow these
runnables to be dispatched to the socket thread.
Differential Revision: https://phabricator.services.mozilla.com/D280953
The PrioritizableRunnable asserted that it runs on the main thread.
In order to prioritize events on the socket thread we also allow these
runnables to be dispatched to the socket thread.
Differential Revision: https://phabricator.services.mozilla.com/D280953
By now, nobody really uses TaskQueue::mName. Bug 1999508 wants to introduce logging and in order to avoid copying strings just for that, we enforce names to be literals.
In a few cases this reduces the level of detail provided in the name (WebRTC, IndexedDB), but given it never showed up (except maybe while debugging) we can probably live without it.
Differential Revision: https://phabricator.services.mozilla.com/D279500
By now, nobody really uses TaskQueue::mName. Bug 1999508 wants to introduce logging and in order to avoid copying strings just for that, we enforce names to be literals.
In a few cases this reduces the level of detail provided in the name (WebRTC, IndexedDB), but given it never showed up (except maybe while debugging) we can probably live without it.
Differential Revision: https://phabricator.services.mozilla.com/D279500
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
This changes a few IDs which have historically been 32-bit integers to
instead be 64-bit integers, reducing the chance of the value
overflowing.
Differential Revision: https://phabricator.services.mozilla.com/D250502
This changes a few IDs which have historically been 32-bit integers to
instead be 64-bit integers, reducing the chance of the value
overflowing.
Differential Revision: https://phabricator.services.mozilla.com/D250502
This changes a few IDs which have historically been 32-bit integers to
instead be 64-bit integers, reducing the chance of the value
overflowing.
Differential Revision: https://phabricator.services.mozilla.com/D250502
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
Daniel Holbert