Skip to content

Commit d5189eb

Browse files
authored
[explainer] Clarify the needs of synchronous mutating operations. (WICG#78)
1 parent 00a1f78 commit d5189eb

File tree

1 file changed

+4
-4
lines changed

1 file changed

+4
-4
lines changed

README.md

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -67,12 +67,12 @@ The following 3 requirements are critical:
6767

6868
One possible requirement that is missing some clarity is
6969

70-
* The beacon should be cancelable.
70+
* The beacon should be updatable after initialization.
7171

7272
This introduces many implementation complications in a multi-process browser.
73-
In order to be resilient to crashes, the beacons must have a presence outside of their process
74-
but in order to be cancellable (without race conditions) the state in process must be authoritative.
75-
If perfectly cancellable beacons are not needed, then the [alternative write-only API](#write-only-api) becomes possible.
73+
In order to be resilient to crashes, the beacons must have a presence outside of their process.
74+
However, in order to allow synchronous mutating operations, e.g. update or cancel, without introducing data races, the state in process must be authoritative.
75+
If perfectly mutating beacons are not needed, then the [alternative write-only API](#write-only-api) becomes possible.
7676

7777
## Design
7878

0 commit comments

Comments
 (0)