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
Previously, in both Read and ReadUTF8, we were doing copies where we did not
need to. Read allocated an nsTArray and passed that to JS, which performed a
copy of its contents to create a Uint8Array. ReadUTF8, on the other hand, would
take that nsTArray, convert it into ns nsString (1 copy), and then pass it to
JS for it to recreate the string (2 copies).
Now, we allocate our string and array buffers up front in JS' memory pools
directly and use the JS API to create the strings and arrays ourselves (instead
of relying on Promise::MaybeResolve() to do a copying conversion). Read now
performs 0 copies in the best case (if the file is not compressed) and ReadUTF8
also does 0 copies in the best case (if the file is not compressed and the
string is ASCII). In the worst case, Read performs a single extra allocation
(to decompress the file) and ReadUTF8 performs 2 (to decompress the file and to
convert a UTF-8 string to either a Latin1 string or a UTF-16 string).
Differential Revision: https://phabricator.services.mozilla.com/D99004
Instead of accepting a DOMString (ie, a UTF16 string) and manually converting
it to UTF-8, we can instead accept a UTF8String from JS, which saves us
manually doing conversions and (and may save an additional conversion if the
JSString* is an ASCII string).
Differential Revision: https://phabricator.services.mozilla.com/D99003
Previously, in both Read and ReadUTF8, we were doing copies where we did not
need to. Read allocated an nsTArray and passed that to JS, which performed a
copy of its contents to create a Uint8Array. ReadUTF8, on the other hand, would
take that nsTArray, convert it into ns nsString (1 copy), and then pass it to
JS for it to recreate the string (2 copies).
Now, we allocate our string and array buffers up front in JS' memory pools
directly and use the JS API to create the strings and arrays ourselves (instead
of relying on Promise::MaybeResolve() to do a copying conversion). Read now
performs 0 copies in the best case (if the file is not compressed) and ReadUTF8
also does 0 copies in the best case (if the file is not compressed and the
string is ASCII). In the worst case, Read performs a single extra allocation
(to decompress the file) and ReadUTF8 performs 2 (to decompress the file and to
convert a UTF-8 string to either a Latin1 string or a UTF-16 string).
Differential Revision: https://phabricator.services.mozilla.com/D99004
Instead of accepting a DOMString (ie, a UTF16 string) and manually converting
it to UTF-8, we can instead accept a UTF8String from JS, which saves us
manually doing conversions and (and may save an additional conversion if the
JSString* is an ASCII string).
Differential Revision: https://phabricator.services.mozilla.com/D99003
Previously, in both Read and ReadUTF8, we were doing copies where we did not
need to. Read allocated an nsTArray and passed that to JS, which performed a
copy of its contents to create a Uint8Array. ReadUTF8, on the other hand, would
take that nsTArray, convert it into ns nsString (1 copy), and then pass it to
JS for it to recreate the string (2 copies).
Now, we allocate our string and array buffers up front in JS' memory pools
directly and use the JS API to create the strings and arrays ourselves (instead
of relying on Promise::MaybeResolve() to do a copying conversion). Read now
performs 0 copies in the best case (if the file is not compressed) and ReadUTF8
also does 0 copies in the best case (if the file is not compressed and the
string is ASCII). In the worst case, Read performs a single extra allocation
(to decompress the file) and ReadUTF8 performs 2 (to decompress the file and to
convert a UTF-8 string to either a Latin1 string or a UTF-16 string).
Differential Revision: https://phabricator.services.mozilla.com/D99004
Instead of accepting a DOMString (ie, a UTF16 string) and manually converting
it to UTF-8, we can instead accept a UTF8String from JS, which saves us
manually doing conversions and (and may save an additional conversion if the
JSString* is an ASCII string).
Differential Revision: https://phabricator.services.mozilla.com/D99003
There are two new lints introduced since IOUtils was written that we're hitting
now:
* IOUtils::InternalFileInfo's constructor does not initialize `mType`, `mSize`,
`mLastModified`, and `mPermissions`; and
* We should be using a nested namespace statement.
We haven't hit them since these lines haven't been touched, but I noticed them
on the code review frontend.
Differential Revision: https://phabricator.services.mozilla.com/D99163
There are two new lints introduced since IOUtils was written that we're hitting
now:
* IOUtils::InternalFileInfo's constructor does not initialize `mType`, `mSize`,
`mLastModified`, and `mPermissions`; and
* We should be using a nested namespace statement.
We haven't hit them since these lines haven't been touched, but I noticed them
on the code review frontend.
Differential Revision: https://phabricator.services.mozilla.com/D99163
Passing in a callable and its arguments to RunOnBackgroundThread was fine
before we started passing in already_AddRefed<nsIFile>. However, if we fail to
get an event target, then we drop all our arguments and in debug builds
already_AddRefed<T> asserts that it was moved out of.
Now we require callers of RunOnBackgroundThread to pass in a closure that
contains all the bindings they require, which has the added bonus of making
lifetimes more explicit. As part of this refactor, all the `ReadSync` etc
methods now take raw nsIFile* pointers since they are called in a scope that
has them refcounted.
Differential Revision: https://phabricator.services.mozilla.com/D98273