Closed
Bug 1360190
Opened 7 years ago
Closed 5 years ago
MessageChannel does not work with SharedArrayBuffer
Categories
(Core :: DOM: Core & HTML, enhancement, P3)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
DUPLICATE
of bug 1605566
People
(Reporter: annevk, Unassigned)
References
(Blocks 2 open bugs)
Details
(Keywords: dev-doc-needed)
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).
Comment 1•7 years ago
|
||
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•7 years 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.
Updated•7 years ago
|
Keywords: dev-doc-needed
Comment 3•7 years ago
|
||
I'm wondering if we can have somebody on the DOM team look at implementing this for FF58?
Flags: needinfo?(overholt)
Comment 4•7 years ago
|
||
We've already got some plans for 58 but maybe this can be fit in.
Flags: needinfo?(overholt)
Comment 5•7 years ago
|
||
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•7 years 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)
Comment 7•7 years ago
|
||
(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•7 years ago
|
||
I think you misunderstood. It's not supposed to be shareable between processes so that part is not a blocker.
Comment 9•7 years 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.
Reporter | ||
Comment 10•6 years ago
|
||
I filed https://github.com/whatwg/html/issues/4209 to track this, given that Google still hasn't after a year.
Assignee | ||
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
Reporter | ||
Updated•5 years ago
|
Priority: P2 → P3
Updated•5 years ago
|
Updated•5 years ago
|
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•