W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > February 2019

Re: [webrtc-pc] transceiver.stop() shouldn't block in-progress replaceTrack from succeeding (#2106)

From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
Date: Tue, 19 Feb 2019 18:44:58 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-465259452-1550601897-sysbot+gh@w3.org>
@youennf I believe you're arguing for less blocking. This issue and PR result in less blocking, so I'm not hearing an argument against merging this.

We should be consistent, and this PR merely aligns with our existing pattern (removing unintended blocking). This isn't theoretical, as we're fixing our Firefox code right now, and would like to merge this spec support to avoid blocking on `stop()`. I suggest opening a separate issue to challenge the overall pattern.

> That may leave code to be hanging forever due to some timing issues.

FWIW I think it's inaccurate to characterize the absence of a callback as "hanging".

-- 
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2106#issuecomment-465259452 using your GitHub account
Received on Tuesday, 19 February 2019 18:45:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 4 June 2019 15:32:55 UTC