- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Tue, 22 Sep 2020 13:55:10 +0000
- To: public-webrtc-logs@w3.org
You may have a better understanding than me, but I don't think I follow. Both tasks are queued in the same maner: > If description is applied successfully, the user agent MUST queue a task that runs the following steps: > - Do some cool stuff. > - ... > - Resolve p with undefined. And: > When the ICE Agent indicates that a new ICE candidate is available for an RTCIceTransport, either by taking one from the ICE candidate pool or gathering it from scratch, the user agent MUST queue a task that runs the following steps: > - Do some cool stuff. > - ... > - Bla bla surface the candidate, i.e. "Fire an event". In both cases we do "queue a task that". So assuming we've queued a task to resolve p and we've queued a task to fire an event, when we do the "execute all tasks" part of the task queue we'll end up making p resolved and the event fired. I'm not sure it matters if then() is handled at the end of the current JS event loop or the start of the next one, as long as resolving p does not synchronously perform then() we have a problem? Is there something I'm missing? Like is there a limit on the number of tasks that can be handled in a single JS task execution cycle? Or is there something say "if any promises have been resolved, stop executing further queued tasks currently pending"? -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2574#issuecomment-696738014 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 22 September 2020 13:55:12 UTC