Previously, if you attempted to read a file greater than INT32_MAX in size, we
would either fail to read the file (on release) or crash (on debug). This is
due to the implementation of _PR_MD_READ accepting an int32_t of bytes to read
instead of a uint32_t, which nsFileStream::Read accepts and passes on.
Differential Revision: https://phabricator.services.mozilla.com/D131161
Presently, if IOUtils encounters an error that it does not know how to map to
a DOMException (via RejectJSPromise), it will only include the nsresult error
code if the IOError was constructed without a message. This hides the root
cause of errors.
Now we always include the error code when rejecting with an UnknownError.
Differential Revision: https://phabricator.services.mozilla.com/D131160
CLOSED TREE
Backed out changeset 55165cf4b7bb (bug 1736175)
Backed out changeset 492f5ca3b592 (bug 1723082)
Backed out changeset ce199e98a0c5 (bug 1741247)
Previously, if you attempted to read a file greater than INT32_MAX in size, we
would either fail to read the file (on release) or crash (on debug). This is
due to the implementation of _PR_MD_READ accepting an int32_t of bytes to read
instead of a uint32_t, which nsFileStream::Read accepts and passes on.
Differential Revision: https://phabricator.services.mozilla.com/D131161
Presently, if IOUtils encounters an error that it does not know how to map to
a DOMException (via RejectJSPromise), it will only include the nsresult error
code if the IOError was constructed without a message. This hides the root
cause of errors.
Now we always include the error code when rejecting with an UnknownError.
Differential Revision: https://phabricator.services.mozilla.com/D131160
This exposes synchronous file reading to workers. It's intended to be used
by profiler symbolication.
The API only supports reading into an existing Uint8Array. This avoids
creating garbage, and minimizes copies.
It also keeps the file open so that it doesn't need to be reopened for
each read.
The implementation uses nsFileStream.
I first tried an implementation which used mmap + memcpy rather than read,
but it didn't work for files larger than 2GiB due to limitations in NSPR's
mmap support, and the profiler needs to read >2GiB files.
Specifically, the profiler sometimes needs to read
/System/Library/dyld/dyld_shared_cache_arm64e , which is 2.2GiB big on
macOS 11.5.
Differential Revision: https://phabricator.services.mozilla.com/D124207
Win32 errors ERROR_DEVICE_HARDWARE_ERROR, ERROR_DEVICE_NOT_CONNECTED, ERROR_DISK_FULL need a mapping.
NS_ERROR_FILE_DISK_FULL is duplicate to NS_ERROR_FILE_NO_DEVICE_SPACE
Drive by: RejectJSPromise lacked some NS_ERROR_* mappings
Differential Revision: https://phabricator.services.mozilla.com/D113974
IOUtils.write{,UTF8,JSON} now support multiple writing modes:
* overwrite, where the contents of the file will be overwritten and a new file
will be created if it does not exist (the old default),
* create, where the file cannot exist and it will be created during the
operation; and
* append, where the file will be appended to.
(Append is not currently supported for writeJSON because appending JSON blobs
together doesn't make sense most of the time.)
Differential Revision: https://phabricator.services.mozilla.com/D113450
IOUtils now provides a shutdown client for clients to register IO jobs with
that need to run before shutdown finishes. This allows IO jobs to run during
the profileBeforeChange phase.
IOUtils' event queuing has been refactored into a singleton EventQueue class,
which is responsible for running tasks and setting up shutdown blockers. It is
now guarded behind a StaticDataMutex so that is more explicitly clear what is
and is not re-entrant. (The atomic sShutdownFinished cannot be placed behind
the mutex because we need to keep track of that state even when we do not have
an EventQueue.)
Differential Revision: https://phabricator.services.mozilla.com/D103973
IOUtils now provides a shutdown client for clients to register IO jobs with
that need to run before shutdown finishes. This allows IO jobs to run during
the profileBeforeChange phase.
IOUtils' event queuing has been refactored into a singleton EventQueue class,
which is responsible for running tasks and setting up shutdown blockers. It is
now guarded behind a StaticDataMutex so that is more explicitly clear what is
and is not re-entrant. (The atomic sShutdownFinished cannot be placed behind
the mutex because we need to keep track of that state even when we do not have
an EventQueue.)
Differential Revision: https://phabricator.services.mozilla.com/D103973
The MOZ_MUST_USE macro is defined as clang's and gcc's nonstandard __attribute__((warn_unused_result)). Now that we compile as C++17 by default (bug 1560664), we can replace MOZ_MUST_USE with C++17's standard [[nodiscard]] attribute.
The [[nodiscard]] attribute must precede a function declaration's declaration specifiers (like static, extern, inline, or virtual). The __attribute__((warn_unused_result)) attribute does not have this order restriction.
Differential Revision: https://phabricator.services.mozilla.com/D107355
IOUtils now provides a shutdown client for clients to register IO jobs with
that need to run before shutdown finishes. This allows IO jobs to run during
the profileBeforeChange phase.
IOUtils' event queuing has been refactored into a singleton EventQueue class,
which is responsible for running tasks and setting up shutdown blockers. It is
now guarded behind a StaticDataMutex so that is more explicitly clear what is
and is not re-entrant. (The atomic sShutdownFinished cannot be placed behind
the mutex because we need to keep track of that state even when we do not have
an EventQueue.)
Differential Revision: https://phabricator.services.mozilla.com/D103973
Previously we were initializing IOUtils lazily when we received our first IO
request, but that could run into problems when
1. shutdown starts before submitting any IO requests, which would then fail to
add shutdown blockers for phases we have already passed; or
2. the first IO request comes from off-main-thread, which can not tell if the
shutdown blockers are added successfully.
Now we register an observer to initialize the event queue and add all startup
blockers in the `profile-after-change` phase. We can then be sure that IOUtils
will have its blockers added before `profile-before-change`.
Differential Revision: https://phabricator.services.mozilla.com/D105700
IOUtils now provides a shutdown client for clients to register IO jobs with
that need to run before shutdown finishes. This allows IO jobs to run during
the profileBeforeChange phase.
IOUtils' event queuing has been refactored into a singleton EventQueue class,
which is responsible for running tasks and setting up shutdown blockers. It is
now guarded behind a StaticDataMutex so that is more explicitly clear what is
and is not re-entrant. (The atomic sShutdownFinished cannot be placed behind
the mutex because we need to keep track of that state even when we do not have
an EventQueue.)
Differential Revision: https://phabricator.services.mozilla.com/D103973
IOUtils now provides a shutdown client for clients to register IO jobs with
that need to run before shutdown finishes. This allows IO jobs to run during
the profileBeforeChange phase.
IOUtils' event queuing has been refactored into a singleton EventQueue class,
which is responsible for running tasks and setting up shutdown blockers. It is
now guarded behind a StaticDataMutex so that is more explicitly clear what is
and is not re-entrant. (The atomic sShutdownFinished cannot be placed behind
the mutex because we need to keep track of that state even when we do not have
an EventQueue.)
Differential Revision: https://phabricator.services.mozilla.com/D103973
RunOnBackgroundThread has been renamed to RunOnBackgroundThreadAndResolve. The
body dealing with calling InvokeAsync for calling a function on the background
event target and returning a MozPromise has been refactored into a new
function, RunOnBackgroundThread.
This allows us to have more complicated IOUtils methods that do not simply
resolve their promises to whatever is returned by the background methods.
Differential Revision: https://phabricator.services.mozilla.com/D99002
RunOnBackgroundThread has been renamed to RunOnBackgroundThreadAndResolve. The
body dealing with calling InvokeAsync for calling a function on the background
event target and returning a MozPromise has been refactored into a new
function, RunOnBackgroundThread.
This allows us to have more complicated IOUtils methods that do not simply
resolve their promises to whatever is returned by the background methods.
Differential Revision: https://phabricator.services.mozilla.com/D99002