2018-09-13 23:04:55 +03:00
|
|
|
/* -*- Mode: IDL; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
|
Bug 1463587: Part 3 - Add bindings for SharedMap, and expose it via process message managers. r=erahm,baku,bz
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
2018-06-30 00:55:27 +03:00
|
|
|
/* This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
* file, You can obtain one at http://mozilla.org/MPL/2.0/.
|
|
|
|
*/
|
|
|
|
|
|
|
|
typedef any StructuredClonable;
|
|
|
|
|
2019-09-27 18:26:14 +03:00
|
|
|
[ChromeOnly, Exposed=Window]
|
Bug 1463587: Part 3 - Add bindings for SharedMap, and expose it via process message managers. r=erahm,baku,bz
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
2018-06-30 00:55:27 +03:00
|
|
|
interface MozSharedMapChangeEvent : Event {
|
|
|
|
[Cached, Constant]
|
|
|
|
readonly attribute sequence<DOMString> changedKeys;
|
|
|
|
};
|
|
|
|
|
|
|
|
dictionary MozSharedMapChangeEventInit : EventInit {
|
|
|
|
required sequence<DOMString> changedKeys;
|
|
|
|
};
|
|
|
|
|
2019-09-27 18:26:14 +03:00
|
|
|
[ChromeOnly, Exposed=Window]
|
Bug 1463587: Part 3 - Add bindings for SharedMap, and expose it via process message managers. r=erahm,baku,bz
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
2018-06-30 00:55:27 +03:00
|
|
|
interface MozSharedMap : EventTarget {
|
|
|
|
boolean has(DOMString name);
|
|
|
|
|
|
|
|
[Throws]
|
|
|
|
StructuredClonable get(DOMString name);
|
|
|
|
|
|
|
|
iterable<DOMString, StructuredClonable>;
|
|
|
|
};
|
|
|
|
|
2019-09-27 18:26:14 +03:00
|
|
|
[ChromeOnly, Exposed=Window]
|
Bug 1463587: Part 3 - Add bindings for SharedMap, and expose it via process message managers. r=erahm,baku,bz
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
2018-06-30 00:55:27 +03:00
|
|
|
interface MozWritableSharedMap : MozSharedMap {
|
|
|
|
/**
|
|
|
|
* Sets the given key to the given structured-clonable value. The value is
|
|
|
|
* synchronously structured cloned, and the serialized value is saved in the
|
|
|
|
* map.
|
|
|
|
*
|
|
|
|
* Unless flush() is called, the new value will be broadcast to content
|
|
|
|
* processes after a short delay.
|
|
|
|
*/
|
|
|
|
[Throws]
|
|
|
|
void set(DOMString name, StructuredClonable value);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Removes the given key from the map.
|
|
|
|
*
|
|
|
|
* Unless flush() is called, the removal will be broadcast to content
|
|
|
|
* processes after a short delay.
|
|
|
|
*/
|
|
|
|
void delete(DOMString name);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Broadcasts any pending changes to all content processes.
|
|
|
|
*/
|
|
|
|
void flush();
|
|
|
|
};
|