W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > June 2017

Re: [webrtc-pc] Race condition in enqueue an operation

From: jan-ivar via GitHub <sysbot+gh@w3.org>
Date: Thu, 22 Jun 2017 22:37:32 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-310521718-1498171050-sysbot+gh@w3.org>
@taylor-b Because we can write non-broken code where it matters:
let haveOffer = pc.createOffer();
pc.addTrack(track, stream);
await haveOffer;

> why does it care if the "synchronous part" of the operation happens immediately

WebIDL does all input validation synchronously, which means we can step over an async function in the JS debugger:
let p = pc.setRemoteDescription(x);
await p;
...and immediately inspect the return value to see if the asynchronous operation got launched or not:
p: Promise { "pending" }

`"pending"` tells us the asynchronous operation was successfully launched. It may fail later for some runtime reason, but it got off the ground (i.e. we at least crossed all the t's and dotted the i's correctly).
p: Promise { "rejected" }
`"rejected"` suggests there was a problem with the inputs, most likely `TypeError` on `x`, and the asynchronous part didn't even get off the ground. I find this helpful when debugging JS.

Where WebIDL falls short, and we need prose to add extra input validation, it makes sense to follow this pattern, both for consistency, and because WebIDL may grow new abilities later, and we may switch to them in the future without side-effects.

We've adopted this approach in both mediacapture and WebRTC.

GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1218#issuecomment-310521718 using your GitHub account
Received on Thursday, 22 June 2017 22:37:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:21:40 UTC