- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Fri, 01 Sep 2017 13:45:04 +0000
- To: public-webrtc@w3.org
henbos has just created a new issue for https://github.com/w3c/webrtc-pc: == Setting local/remote descriptions in succession without waiting for the promises to resolve == The setting of an RTCSessionDescription says to "In parallel, start the process to apply _description_ as described in ..." which does things based on the PC's state. This, along with other function calls or tasks queued that get and set the PC and other objects' states, would seem unsafe. Is there a lock implied, and does "in parallel" mean "queue a task to do in parallel"? Doing multiple SRDs in succession without waiting for promises to resolve might have indeterminate effects due to races - _even if we protect the PC's state with locks_ such that if a task is executed in any context all of it is executed before any other task is executed: ``` pc.ontrack = (e) => { console.log(e.streams[0].getTracks().length); } pc.setRemoteDescription() such that stream x with track y is added pc.setRemoteDescription() such that stream x with track y is removed ``` The spec says that when the process to apply the description is finished a task is queued to do things, including queuing tasks to fire ontrack events. Note the "queue a task to queue a task". This means that even with locks protecting the PC's state the order of firing the first ontrack event and executing the task after the second SRD process finished is racey. In the first ontrack event, stream x could contain track y or it could be empty. Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1569 using your GitHub account
Received on Friday, 1 September 2017 13:45:04 UTC