MessageChannel does not work with SharedArrayBuffer

NEW
Unassigned

Status

()

Core
DOM
P2
normal
a year ago
9 months ago

People

(Reporter: annevk, Unassigned)

Tracking

(Blocks: 1 bug, {dev-doc-needed})

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

a year ago
Tests: https://github.com/w3c/web-platform-tests/pull/5003.

Related: bug 1359017 (we need to dispatch messageerror when the shared buffer ends up in a different agent cluster).
I spoke with Anne and he confirmed SAB "v1" can ship without this but we want to fix it soon.
Priority: -- → P2
(Reporter)

Comment 2

a year ago
We should probably also use this bug for BroadcastChannel since I suspect it's very much the same underlying problem. Happy to split it out if desired though.
Keywords: dev-doc-needed

Comment 3

9 months ago
I'm wondering if we can have somebody on the DOM team look at implementing this for FF58?
Flags: needinfo?(overholt)
Depends on: 1359017
We've already got some plans for 58 but maybe this can be fit in.
Flags: needinfo?(overholt)
At the spec level, is SAB supposed to be shareable between processes? baku and smaug indicated that was a blocker here.
Flags: needinfo?(annevk)
(Reporter)

Comment 6

9 months ago
No it's not. When you share it outside an agent cluster the receiving party gets a messageerror event. I explained the setup in more detail to baku and smaug on IRC.

Via private email I heard there are some concerns around the difficulty of implementing the standard correctly in Google Chrome. lth seemed to echo those for Firefox, but thus far nobody raised a public issue to discuss the matter so I'm not sure what the status is there.
Flags: needinfo?(annevk)
(In reply to Anne (:annevk) from comment #6)
> No it's not.

OK so I guess we need to get SAB to be usable across content processes (some sort of shared memory?) before we do this (otherwise we'd expose that implementation detail if we, say, restricted things to receiving parties in the same process).
(Reporter)

Comment 8

9 months ago
I think you misunderstood. It's not supposed to be shareable between processes so that part is not a blocker.

Comment 9

9 months ago
What Anne said.  Plus:

The concern that has come up in discussion elsewhere is the following.  It is possible for a SAB to flow from agent A in process 1 to agent B in process 2 and then back to agent C in process 1 again, where A and C are in the same cluster, in a very convoluted way: if the value that flows from A to B to C is not a SAB but is instead a channel object that contains a SAB - a SAB has been enqueued on the channel but nobody's read it yet.  (Communication would be by broadcast, I guess.)  If B were to try to receive from the channel it received it would see a message error because it cannot receive that SAB.  But that's not what happens, it just forwards the channel back to process 1.

Now: can C receive the SAB that was hidden in the channel that travelled cross-process?

My feeling is that the answer should probably be "no" because the implication of a "yes" means we'll need some kind of cross-process RC or GC if our SABs cannot normally travel cross-process: when the port containing the SAB travels out of process 1, process 1 must be prepared for the possibility that the port eventually comes back and picks up the SAB again.  But an answer of "no" to the question only means we need some kind of management of the latent contents of channels that are passed out of processes as values.

It would be surprising to me if Google thought differently, since they raised the issue in the first place.
You need to log in before you can comment on or make changes to this bug.