This makes the naming more consistent with other functions called
Insert and/or Update. Also, it removes the ambiguity whether
Put expects that an entry already exists or not, in particular because
it differed from nsTHashtable::PutEntry in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D105473
It should be called "Get" rather than "Lookup" because it returns
UserDataType. "Add" is called "Insert" in the other methods.
Differential Revision: https://phabricator.services.mozilla.com/D105470
This just splits out the InputBuffer and OutputBuffer helper classes
to make it cleaner for the StartupCache to include them.
Differential Revision: https://phabricator.services.mozilla.com/D34651
--HG--
extra : moz-landing-system : lando
This just splits out the InputBuffer and OutputBuffer helper classes
to make it cleaner for the StartupCache to include them.
Differential Revision: https://phabricator.services.mozilla.com/D34651
--HG--
extra : moz-landing-system : lando
This logging topic will output the topic of MEssageManager data at log
level 4 (debug); and will output the entire content of the data at level
5 (verbose).
--HG--
extra : histedit_source : 7be60b456a1652f9a9985fd4a01571b207a5f9e6
This is mostly self-explanatory. However, the patch also contains some minor
changes to frame scripts which expect to be able to call message manager
methods with a null target object, which stops working when they stop being
global objects.
MozReview-Commit-ID: HDT2RvK3F3L
--HG--
extra : rebase_source : bb3ce8861a261ff1bc28a28b3ff88ba0deaef552
After these patches, these objects will no longer be globals, which would make
their current names misleading. Parts 1a-1c give more appropriate names to the
bindings which will cease to be globals.
MozReview-Commit-ID: L8GolQaHnO5
--HG--
rename : dom/base/ProcessGlobal.cpp => dom/base/ContentProcessMessageManager.cpp
rename : dom/base/ProcessGlobal.h => dom/base/ContentProcessMessageManager.h
extra : rebase_source : c5db43ff4f56bc27c869a8051c8d2c000b3fe287
We were previously failing to send blobs to new content processes, which was a
problem for those processes. But we were also attempting to extract blobs for
new entries that we were serializing after we'd extracted their structured
clone data, and their blob array had been thrown away (which was a problem for
all processes).
This patch fixes both problems.
MozReview-Commit-ID: 3qbAmUTA85g
--HG--
extra : rebase_source : 87ed9356aa23ae83762a887cf12ba1f466e7bf61
I was hoping to avoid supporting blobs here, but some parts of the
WebExtensions framework rely on being able to store Blobs in
initialProcessData, and can't be migrated without adding blob support.
This patch adds an ordered array of BlobImpls for all extant keys, clones them
to all child processes when updating the serialized maps, and initializes
StructuredCloneData instances with indexes into the combined array.
MozReview-Commit-ID: IdSv5FHbPbE
--HG--
extra : rebase_source : 90eeb7fad21eac93582ef9244180998d22267373
extra : source : cebf1f055d1dfb505e96cebf7e4284b35a419dd6
This is the first basic implementation of a shared-memory key-value store for
JS message managers. It has one read-write endpoint in the parent process, and
separate read-only endpoints for each child-process message manager.
Changes to the parent endpoint are broadcast to the children as snapshots.
Each snapshot triggers a "change" event with a list of changed keys.
It currently has the following limitations:
- It only supports basic structured clone data. There's no support for blobs,
input streams, message ports... Blob support will be added in a follow-up
patch.
- Changes are currently only broadcast to child endpoints when flush() is
explicitly called in the parent, or when new child processes are launched.
In a follow-up, this will be changed to automatically flush after changes
when the event loop is idle.
- All set operations clone their inputs synchronously, which means that
there's no trivial way for callers to batch multiple changes to a single key
without some additional effort. It might be useful to add a
delayed-serialization option to the .set() call in a follow-up, for callers
who are sure they know what they're doing.
MozReview-Commit-ID: IM8a3UgejXU
--HG--
extra : rebase_source : 66c92d538a5485349bc789028fdc3a6806bc5d5a
extra : source : 2ebaf5f8c6055b11b11d7ec334d54ee941115d48
This class allows one read-write copy of a map in the parent process to share
data with multiple read-only copies in child processes. The maps only hold
onto data as structured clone blobs, and deserialize them each time a key is
read.
This commit only provides the bare-bones data structures. Follow-ups will add
bindings, change events, and automatic flushes.
MozReview-Commit-ID: LimwfmFBNOi
--HG--
extra : rebase_source : e43985c39bd1cfd05a2ad536b0d7f74db494a753
extra : source : c27295337b4c16e2a178106a3aa873d2a0e5a1f4
I was hoping to avoid supporting blobs here, but some parts of the
WebExtensions framework rely on being able to store Blobs in
initialProcessData, and can't be migrated without adding blob support.
This patch adds an ordered array of BlobImpls for all extant keys, clones them
to all child processes when updating the serialized maps, and initializes
StructuredCloneData instances with indexes into the combined array.
MozReview-Commit-ID: IdSv5FHbPbE
--HG--
extra : rebase_source : 3020af12859ce3470bd31e9c3b7f5c919e1b9665
This is the first basic implementation of a shared-memory key-value store for
JS message managers. It has one read-write endpoint in the parent process, and
separate read-only endpoints for each child-process message manager.
Changes to the parent endpoint are broadcast to the children as snapshots.
Each snapshot triggers a "change" event with a list of changed keys.
It currently has the following limitations:
- It only supports basic structured clone data. There's no support for blobs,
input streams, message ports... Blob support will be added in a follow-up
patch.
- Changes are currently only broadcast to child endpoints when flush() is
explicitly called in the parent, or when new child processes are launched.
In a follow-up, this will be changed to automatically flush after changes
when the event loop is idle.
- All set operations clone their inputs synchronously, which means that
there's no trivial way for callers to batch multiple changes to a single key
without some additional effort. It might be useful to add a
delayed-serialization option to the .set() call in a follow-up, for callers
who are sure they know what they're doing.
MozReview-Commit-ID: IM8a3UgejXU
--HG--
extra : rebase_source : 8e8b7891ca48e61b2d6ba3c05912064a909d9698
This class allows one read-write copy of a map in the parent process to share
data with multiple read-only copies in child processes. The maps only hold
onto data as structured clone blobs, and deserialize them each time a key is
read.
This commit only provides the bare-bones data structures. Follow-ups will add
bindings, change events, and automatic flushes.
MozReview-Commit-ID: LimwfmFBNOi
--HG--
extra : rebase_source : a6959c9f3186af7252ac2899f6801d5e02b62222
Simon Giesecke
Alexandru Michis
Noemi Erli
smolnar
Sylvestre Ledru
Butkovits Atila
Doug Thayer
Cosmin Sabou
Kris Maglione
Ryan Hunt
Randell Jesup
Tom Ritter
Tooru Fujisawa
Margareta Eliza Balazs