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: Mon, 25 Feb 2019 22:41:28 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-467213864-1551134487-sysbot+gh@w3.org>
FWIW I don't think it's obvious how async operations should react to close/abort/navigation. Happy to look at other APIs, but most specs don't discuss navigation at all.

Without rehashing https://github.com/w3c/webrtc-pc/issues/150#issuecomment-152333247, it's worth noting "cancelable promises" were hotly debated at the time, with a potential "third rail" of propagation for cancellation solely thru `finally` statements.

That got scrapped. Instead, `fetch` adopted a simpler [abortController](https://developers.google.com/web/updates/2017/09/abortable-fetch) model that rejects with `AbortError`. This might count as new information if you want to re-open the issue.

I think we need practical reasons though. There's nothing inherently wrong with pending promises:
(async () => {
  let id;
  button.onclick = () => clearTimeout(id);
  await new Promise(r => id = setTimeout(r, 10000));
  console.log("The sky is falling");

const id = setTimeout(() => console.log("No-one cared ever"), 10000);
button.onclick = () => clearTimeout(id);
Garbage collection cleans up both AFAIK.

I think we need to ask: Why would an app want renegotiation errors after having called `pc.close()`?

GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2106#issuecomment-467213864 using your GitHub account
Received on Monday, 25 February 2019 22:41:29 UTC

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