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