Closed Bug 1069316 Opened 5 years ago Closed 3 years ago

Figure out interaction of SharedWorker, SharedArrayBuffer, and e10s with processCount > 1

Categories

(Core :: JavaScript Engine, defect)

x86
macOS
defect
Not set

Tracking

()

RESOLVED FIXED
Tracking Status
e10s + ---

People

(Reporter: lth, Unassigned)

References

(Blocks 1 open bug)

Details

Based on conversations with Bill I believe that it is not necessarily the case that two tabs from the same domain will be running in the same process under e10s.

Yet those two tabs can both have access to the same SharedWorker.  Ergo that worker is in another process than at least one of those tabs.

If that SharedWorker is handed a reference to a SharedArrayBuffer created by the tab that is not in the same process as the worker then the memory for that buffer must be shared (and managed) across processes.  There is no code in place for that today.

Bill points out that at a minimum we could prohibit shared memory from being used with the SharedWorker.
At present I do not understand how the problem can arise.  It looks like a SharedWorker currently lives entirely within a process and is not visible outside it: If there's a cross-process commmunication channel that allows JS code in one process to reify a SharedWorker that already exists in another process I have not found it.
See Also: → 1232973
Bug 1232973 will offer code to disable sharing of memory to/from SharedWorker and ServiceWorker.
Depends on: 1232973
See Also: 1232973
I think this works fine with a single content process, but will need to be addressed for multiple content processes
Blocks: e10s-multi
Summary: Figure out interaction of SharedWorker, SharedArrayBuffer, and e10s → Figure out interaction of SharedWorker, SharedArrayBuffer, and e10s with processCount > 0
Summary: Figure out interaction of SharedWorker, SharedArrayBuffer, and e10s with processCount > 0 → Figure out interaction of SharedWorker, SharedArrayBuffer, and e10s with processCount > 1
Flags: needinfo?(gkrizsanits)
I think for M1 we only need bug 1232973.
Flags: needinfo?(gkrizsanits)
(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #3)
> I think this works fine with a single content process, but will need to be
> addressed for multiple content processes

Well, with e10s you still have 1 parent and 1 content process. And I was just told that because of this situation shared workers are not supported in webextensions (bug 1302712). so even with processcount=1 it's an issue.
On the standards side, there is some movement here: we're initially going to allow sharing of a SharedArrayBuffer within what is effectively a single DocGroup.  A plausible solution for this (in the presence of first-class channels and broadcast channels) is to tag a SharedArrayBuffer with its pid+tabgroup+docgroup on serialization and check the tag on deserialization.
See Also: → 1359461
The standards side of this has now been worked out, see https://github.com/whatwg/html/issues/2260, https://github.com/whatwg/html/pull/2520, https://github.com/whatwg/html/pull/2521, https://github.com/w3c/ServiceWorker/issues/1115, and links off those.

Getting the standards story straight effectively "fixes" this bug.  I'm going it because it is superseded by other, properly specific bugs:

* Allow blocking waits in SharedWorker instances: bug 1359745.
* Allow SharedArrayBuffer objects to be transmitted over MessageChannels and BroadcastChannels, bug 1360190.
* Implement the MessageError event, bug 1359017.
* Other corner cases, bug 1360434.
Assignee: lhansen → nobody
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
I should also have noted that as explained in bug 1232973 comment 16, what we have now is incorrect (really too limited) as per the HTML spec but safe as far as e10s-multi is concerned, so far as I can figure it.
You need to log in before you can comment on or make changes to this bug.