- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Sun, 03 May 2015 22:52:45 +0200
- To: public-webrtc@w3.org
On 05/03/2015 08:41 PM, Stefan Håkansson LK wrote: > On 03/05/15 18:07, Harald Alvestrand wrote: >> The problem we're facing is caused by an interesting omission: >> >> None of addTrack or createOffer specifies what, if any, action is >> performed in a synchronous part before the asynchronous part starts. >> >> The text says >> >> The general idea is to have only one among createOffer, >> setLocalDescription, createAnswer and setRemoteDescription executing at >> any given time. If subsequent calls are made while one of them is still >> executing, they are added to a queue and processed when the previous >> operation is fully completed. >> >> This *seems* to indicate that every piece of the method is executed in >> the asynchronous part - including the adding of tracks to the list that >> createOffer reads from. >> >> That means that Jan-Ivar's resolution is simply wrong: If you call >> >>>>>>> var senderX = pc.addTrack(trackX); >>>>>>> pc.createOffer(); >>>>>>> var senderY = pc.addTrack(trackY); >> then the following will happen: >> >> - the JS will run to completion >> - addTrack(trackX) will execute, and its promise will resolve > AFAIK addTrack is synchronous, and there is no promise to resolve > (instead a RTPSender is synchronously returned). > > This means to me that Jan-Ivar's resolution can be correct unless we > change addTrack. Ouch. I misread this part. We are changing the tracks structure outside the operations queue by AddTrack. I think that's a mistake, but I can't argue that it's not in the spec :-(
Received on Sunday, 3 May 2015 20:53:14 UTC