- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Tue, 31 Mar 2020 21:01:50 +0000
- To: public-webrtc-logs@w3.org
If the net result is the same - fingers crossed - then Chrome acts almost like what this PR is proposing. Not by doing what the PR proposes, though. Here's a codepen: https://codepen.io/henbos/pen/dyorzjV?editors=0010 If you run it in Chrome, I think you get the intended behavior except that the associated addTrack transceiver has its mid attribute exposed too early. Chrome has a threading model that I have been arguing against for years, but while it blocks threads (undesired) it does have the benefit of always having a well-defined order. Here's what happens: JS calls SRD() and addTrack() without awaiting in-between. SRD() starts in-parallel work. The JS addTrack() blocks until JSEP has performed addTrack(), and then exposes the resulting transceiver. When SRD is done, a PostTask ensures transceivers get synchronized on the JS thread. Our implementation does not perform addTrack() "synchronously" rather it fakes being synchronous by blocking the thread. On the JSEP thread however everything is single-threaded. On this thread, SRD() always gets executed first. This means that AddTrack() has a transceiver to recycle. When this is surfaced to JS, it exposes a new transceiver that is added to webrtc-pc's set of transceivers - even if this transceiver was created as the result of an in-parallel operation. Later, the task that was posted by SRD completing gets executed, and transceivers get synchronized to match the SRD callback. -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/2504#issuecomment-606873267 using your GitHub account
Received on Tuesday, 31 March 2020 21:01:53 UTC