Raised by @jimblandy.

In practice, async pipeline creation should basically happen in two steps: kicking off the pipeline creation on a thread, and then when it's done, forwarding the result back to the content timeline.

We are pretty handwavy about this, because we don't actually explicitly run work on a separate thread:

• When pipeline is ready to be used or has been invalidated:
  • Let valid be pipeline’s valid state.
  • Issue the subsequent steps on contentTimeline.

• However the timing of various steps here should be clearer - the red block of "device timeline steps" is not actually one atomic "task" for the device timeline, but two.
• Corentin noted that the device timeline steps are not totally stateless - the call into the synchronous create*Pipeline method does check the device-loss state. The spec should allow create*PipelineAsync to race with a device loss event. (The observable difference is when you try to create an invalid pipeline - pipeline creation "succeeds" unconditionally if the device is lost.)
• mapAsync handles this in quite a lot more detail: https://gpuweb.github.io/gpuweb/#dom-gpubuffer-mapasync
  • (though it still only uses one device timeline block, not two, so that could be improved too)
• as does popErrorScope though it's a bit different since it's not asynchronous: https://gpuweb.github.io/gpuweb/#dom-gpudevice-poperrorscope
• FWIW getCompilationInfo doesn't handle device loss at all and probably should.