Avoiding race conditions in parallel exclusive session requests

[offenwanger]

Currently the spec does not define how race conditions between multiple exclusive session requests should be handled.
https://immersive-web.github.io/webxr/#dom-xrdevice-requestsession

For example: If Request A starts and is held up in stage 7, then Request B starts while A is outstanding, what should the behavior of B be?

Proposal:

• Request A
• Request B
• B is blocked while A is outstanding
• If A succeeds reject B
• If A fails allow B to proceed

[RafaelCintron]

I suggest we reject new exclusive mode session requests while there are any outstanding. Since exclusive mode requests involve user consent UI, reducing the number of interleaving prompts is desired.

Edge currently takes this approach for WebVR.

[Artyom17]

Rafael's solution sounds totally reasonable to me.

[jsantell]

Third'ing Rafael's solution, and seems to work nice with attempting multiple potential session configurations outside of exclusivity when probing for overlaps between supported feature sets by device and the application:

  async onStart() {
    const device = await navigator.xr.requestDevice();
    const featureSets = [{ exclusive: true, featureA: true }, { exclusive: true, featureB: true }];
    let session;

    while (!session && featureSets.length) {
      try {
        session = await device.requestSession(featureSets.shift());
      } catch (e) {}
    }
  }

It seems to be dangerous from an application logic perspective to allow multiple in-flight exclusive requests, although interested in learning more about why a request would take "too long" (10 seconds?) in order to queue up another request. Is that something that can happen?

[toji]

FWIW I believe that Rafael's solution was what was agreed to on the previous WebXR call as well. I'll put up a pull request soon to document it.

[AdaRoseCannon]

@toji Does this PR close this issue?