Open
Bug 1209163
Opened 9 years ago
Updated 2 months ago
[Meta] Make RTCDataChannels transferable (to workers)
Categories
(Core :: WebRTC: Networking, enhancement)
Core
WebRTC: Networking
Tracking
()
NEW
People
(Reporter: jesup, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: meta, parity-chrome, parity-safari)
From my posting to the W3 public-webrtc list. The PR is 317
Use-case:
A number of applications using RTCDataChannels would benefit from being able to process the data and send data from a Worker. An example of this is a game which handles state updates and other processing in a Worker, keeping the mainthread application free to handle rendering and UI interactions, and avoiding or minimizing GC pauses.
Basic Mechanism:
The RTCDataChannel would be a transferrable object, which can be sent via postMessage:
channel = createDataChannel("MyChannel", {});
// or we're in an ondatachannel callback/event triggered by the other
// side creating an RTCDataChannel
worker.postMessage(channel, [channel]);
// channel is now owned by the worker; no more events will occur on the
// sender's version of 'channel'
The worker will receive the object, and can set event handlers on it.
Handling of Events:
After a transfer, all events occur in the worker, and the worker must set up event handlers to process them. Any events that occur during the transfer, or that were queued to be fired in the sender, will be held until the worker gets the transferred object. This means the worker should set EventHandlers on the channel immediately on receiving the channel.
Close:
The worker can call channel.close(), which will operate normally. If the PeerConnection is shut down via peerconnection.close(), or if the RTCDataChannel m=application line is renegotiated 'off', then the worker will receive a close event for the channel, as normal.
An RTCDataChannel may be transferred at any time, and may be transferred more than once.
Reporter | ||
Updated•9 years ago
|
backlog: --- → webrtc/webaudio+
Rank: 25
Updated•9 years ago
|
Keywords: dev-doc-needed
Reporter | ||
Updated•9 years ago
|
Rank: 25 → 15
Priority: P2 → P1
Updated•9 years ago
|
Rank: 15 → 23
Priority: P1 → P2
Comment 1•7 years ago
|
||
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3
Comment 2•3 years ago
|
||
Hi Byron, is this on the roadmap at all?
- WebKit has implemented it, and it shipped in Safari about a year ago — https://trac.webkit.org/changeset/274758/webkit/
- Blink hasn’t yet implemented it; feature bug is https://bugs.chromium.org/p/chromium/issues/detail?id=1244165
Flags: needinfo?(docfaraday)
Comment 3•3 years ago
|
||
We do not have any near-term plan to implement this at the moment, since we have an excess of P1/P2 work.
Flags: needinfo?(docfaraday)
Updated•2 years ago
|
Severity: normal → S3
Updated•2 years ago
|
Type: defect → enhancement
Comment 4•2 years ago
|
||
Something like this can't be polyfilled nicely. would be great if this could be supported natively 🙏
Besides Safari this now also has been implemented by Blink (will be available in Chrome v130).
Updated•3 months ago
|
Severity: S3 → S2
Rank: 23
Keywords: dev-doc-needed → meta
Summary: Make RTCDataChannels transferable (to workers) → [Meta] Make RTCDataChannels transferable (to workers)
Updated•3 months ago
|
Priority: P3 → --
Updated•3 months ago
|
backlog: webrtc/webaudio+ → ---
status-firefox44:
affected → ---
Updated•2 months ago
|
Keywords: parity-chrome,
parity-safari
You need to log in
before you can comment on or make changes to this bug.
Description
•