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

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:
```js
(async () => {
  let id;
  button.onclick = () => clearTimeout(id);
  await new Promise(r => id = setTimeout(r, 10000));
  console.log("The sky is falling");
})();
```

```js
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