mapSync on Workers - and possibly on the main thread #2217
Description
In principle, AFAIU, synchronous blocking APIs are only problematic on the main thread. Web workers can block on operations without really causing any problems - especially since our operations should never block for very long (unlike network operations for example, although synchronous XHR is not a good example because it's old).
We could mirror some APIs into synchronous versions with [Exposed=DedicatedWorker].
Definitely useful - I'd start with just this one:
- mapAsync
EDIT: There are other possible entry points but let's ignore them for now
Maybe useful but possibly not worth the complexity:
- compilationInfo
- onSubmittedWorkDone
- popErrorScope
Most likely not needed:
- requestAdapter
- requestDevice
- device.lost
Synchronous map (mapSync) is known to be particularly handy. For example, TensorFlow.js can implement its dataSync() method to synchronously read data back from a gpu-backed tensor (even if only available on workers).
Finally, there's no avoiding the fact that poorer forms of synchronous readback are always going to be available (e.g. synchronous canvas readback) so we should at least consider supporting mapSync on workers where it's OK in principle.
EDIT:
A possible direction on this issue is that we just give up and start allowing blocking readbacks in general, even on the main thread. I know we're operating under strong architectural guidance that we don't do this. But in practice it's just forcing people to do terrible workarounds with canvases (reshaping/re-encoding data into 2D rgba8unorm data, writing it into a canvas, and then using existing synchronous readback APIs like toDataURL to read them). Maybe we should get out of the business of trying to force people do to the "right thing" when the wrong thing is already possible, and just provide the primitives. The performance consequences of synchronous readback are not that bad (compared with e.g. synchronous XHR).
Originally posted by @kainino0x in #2217 (comment)