- From: jan-ivar via GitHub <sysbot+gh@w3.org>
- Date: Thu, 22 Jun 2017 19:56:46 +0000
- To: public-webrtc-logs@w3.org
**TL;DR;** The operations queue is legacy tech; it's more important that it operates as if it's not there in the typical case (empty queue). @soareschen We discussed this ad nauseum [3 years ago](https://lists.w3.org/Archives/Public/public-webrtc/2015May/0064.html) to arrive at the logic we have now. I don't think anyone wishes to reopen this topic. The operations queue is legacy tech. In other words, well-behaved code does not rely on it: ```js await pc.setRemoteDescription(incoming.sdp); await pc.createAnswer()); // not relying on queue ``` Only old-style broken code relies on it: ```js pc.setRemoteDescription(incoming.sdp); pc.createAnswer(); // relies on queue ``` The old code should already be considered "broken" because it does not propagate errors correctly. It also has the races you observe. That means we put more value in preserving the synchronous nature of the synchronous halves of the operations (as if the operations queue did not exist) rather than worry about races when the queue is used. > For example, if the next line of code is peerconnection.close(), then the operation may or may not be executed depending on the operation queue length. Not so, because all enqueued operations are defined to stall on `close`. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1218#issuecomment-310485555 using your GitHub account
Received on Thursday, 22 June 2017 19:56:52 UTC