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

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Lars T Hansen [:lth]]

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.

Comment 1

[Lars T Hansen [:lth]]

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.

Comment 2

[Lars T Hansen [:lth]]

Bug 1232973 will offer code to disable sharing of memory to/from SharedWorker and ServiceWorker.

Comment 3

[Brad Lassey [:blassey] (use needinfo?)]

I think this works fine with a single content process, but will need to be addressed for multiple content processes

Comment 4

[Gabor Krizsanits (INACTIVE)]

I think for M1 we only need bug 1232973.

Comment 5

[The 8472]

(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.

Comment 6

[Lars T Hansen [:lth]]

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.

Comment 7

[Lars T Hansen [:lth]]

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.

Comment 8

[Lars T Hansen [:lth]]

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.