`mParamsArray` doesn't need to be released on the main-thread as it doesn't
contain anymore instances of XPCVariant. The variants used are derived from
thread-safe Storage Variant_base.
Differential Revision: https://phabricator.services.mozilla.com/D220100
This also fixes a bug in the test_connection_online_backup.js test which wasn't
properly evaluating that the page_size PRAGMA was being copied properly.
Differential Revision: https://phabricator.services.mozilla.com/D207471
Sorry for the massive patch but I found it hard to split without
introducing a bunch of copies around...
This mostly makes necko and DOM agree on which strings to use, which
should result on less copies and conversions.
Differential Revision: https://phabricator.services.mozilla.com/D205601
This changes comes with several different refactorings all rolled into one,
unfotunately I couldn't find a way to pull them apart:
- First of all annotations now can either recorded (that is, we copy the value
and have the crash reporting code own the copy) or registered. Several
annotations are changed to use this functionality so that we don't need to
update them as their value change.
- The code in the exception handler is modified to read the annotations from
the mozannotation_client crate. This has the unfortunate side-effect that
we need three different bits of code to serialize them: one for annotations
read from a child process, one for reading annotations from the main process
outside of the exception handler and one for reading annotations from the
main process within the exception handler. As we move to fully
out-of-process crash reporting the last two methods will go away.
- The mozannotation_client crate now doesn't record annotation types anymore.
I realized as I was working on this that storing types at runtime has two
issues: the first one is that buggy code might change the type of an
annotation (that is record it under two different types at two different
moments), the second issue is that types might become corrupt during a
crash, so better enforce them at annotation-writing time. The end result is
that the mozannotation_* crates now only store byte buffers, track the
format the data is stored in (null-terminated string, fixed size buffer,
etc...) but not the type of data each annotation is supposed to contain.
- Which brings us to the next change: concrete types for annotations are now
enforced when they're written out. If an annotation doesn't match the
expected type it's skipped. Storing an annotation with the wrong type will
also trigger an assertion in debug builds.
Differential Revision: https://phabricator.services.mozilla.com/D195248
This utility copies an SQLite database, but does so just by performing a file
copy on the database itself. It assumes that there are no open connections on
the underlying database file.
Given that this is only used by Places, and that a later patch in this stack
adds a database backup utility that works even if there are open connections,
means we can move this old utility out form the mozIStorageService and into
a dedicated Places helper instead.
Differential Revision: https://phabricator.services.mozilla.com/D198309
The API can only load from a predetermined list of extensions statically built
in the same library as SQLite (either nss3 or mozsqlite3 at this time).
New extensions must be audited and their code updated through the update.sh
script.
All the extensions should be compilable and usable across all the tier1
platforms and from Rusqlite.
Differential Revision: https://phabricator.services.mozilla.com/D191316
Move SQLite updates to the `mach vendor` system to simplify updates.
This will have to be invoked manually through `./mach vendor`, as updatebot
is not hooked up yet (tracking new versions through Github tags is not reliable).
Build FTS5 statically in the same library as SQLite, but as a run-time
loadable extension.
Other extensions will similarly be added in the future, consumers can then use
mozStorage `loadExtension()` or Rusqlite `load_extension()` to load them.
FTS5 is used as a first example and for unit tests. While it could be enabled
statically, we prefer to have it on-demand and per connection.
Differential Revision: https://phabricator.services.mozilla.com/D191314
Move SQLite updates to the `mach vendor` system to simplify updates.
This will have to be invoked manually through `./mach vendor`, as updatebot
is not hooked up yet (tracking new versions through Github tags is not reliable).
Build FTS5 statically in the same library as SQLite, but as a run-time
loadable extension.
Other extensions will similarly be added in the future, consumers can then use
mozStorage `loadExtension()` or Rusqlite `load_extension()` to load them.
FTS5 is used as a first example and for unit tests. While it could be enabled
statically, we prefer to have it on-demand and per connection.
Differential Revision: https://phabricator.services.mozilla.com/D191314
The API can only load from a predetermined list of extensions statically built
in the same library as SQLite (either nss3 or mozsqlite3 at this time).
New extensions must be audited and their code updated through the update.sh
script.
All the extensions should be compilable and usable across all the tier1
platforms and from Rusqlite.
Differential Revision: https://phabricator.services.mozilla.com/D191316
Move SQLite updates to the `mach vendor` system to simplify updates.
This will have to be invoked manually through `./mach vendor`, as updatebot
is not hooked up yet (tracking new versions through Github tags is not reliable).
Build FTS5 statically in the same library as SQLite, but as a run-time
loadable extension.
Other extensions will similarly be added in the future, consumers can then use
mozStorage `loadExtension()` or Rusqlite `load_extension()` to load them.
FTS5 is used as a first example and for unit tests. While it could be enabled
statically, we prefer to have it on-demand and per connection.
Differential Revision: https://phabricator.services.mozilla.com/D191314
Not using a pref because Storage has connections using helper threads and the
main thread, thus we prefer to avoid mutex costs for a pref we'll likely not
use in Firefox. Also using a "once" pref would require some coordination because
Storage may try to lazy init once prefs from different threads concurrently,
causing potential deadlocks.
Differential Revision: https://phabricator.services.mozilla.com/D183724
Marco Bonardo
Florian Quèze
Niklas Baumgardner
Emilio Cobos Álvarez
Jari Jalkanen
Ryan VanderMeulen
Mike Conley
abhishekmadan30
Iulian Moraru
Noemi Erli
Gabriele Svelto
Dave Townsend
Tomislav Jovanovic
Joel Maher
Butkovits Atila
Patryk Gruszka
Sandor Molnar
Sylvestre Ledru
Sylvestre Ledru
Cristina Horotan
hsingh
Marco Bonardo
Norisz Fay
Mark Banner