How common are the blocking API calls? Can we somehow predict whether the SWF will need that, and optionally use a worker/non-worker context based on that?
We can do whatever we like in Gecko, but I'd imagine that any proposal to allow blocking on a worker will meet significant resistance in the WG (which is, IMO, justified). bholley On Mon, Oct 14, 2013 at 5:03 PM, Benjamin Smedberg <benja...@smedbergs.us> wrote: > One of the shumway goals has been to run most or all of shumway in a worker, > so that it can run in parallel with a web page the same way Flash currently > does. This will significantly help solve jank associated with shumway > loading. > > However, we still need to support the Flash externalInterface scripting > layer, which is synchronous with respect to content. This exposes race > conditions between the SWF runtime and content; we have already solved this > for out-of-process plugins by introducing an explicit race resolution policy > (the plugin wins races). > > Having this blocking interface will also support blocking shumway on > graphics rendering; there are a fair number of SWF files that use an API to > get a synchronous bitmap of their stage, which requires a blocking call from > shumway to the main thread even after we get canvas-on-a-worker, which > explicitly will not support that blocking case. > > I would like to know whether it is possible to support blocking between > content and a worker to support this scripting use case. > > I'm fine with supporting this only for shumway as a special case, but I'm > interested in discussing whether we can expose this to workers in general. > We don't want to make blocking on workers a way to bypass asynchronous I/O > checks: for instance normally workers can do synchronous indexeddb calls > while the main thread can't. But perhaps we can expose a flag when you > create a worker which allows it to *either* have blocking calls *or* > blocking I/O, but not both? > > In general we expect shumway to be mainly non-blocking, so we'd usually get > parallelism improvements from having it on a worker, while retaining support > for the special cases where blocking is necessary for compatibility. > > --BDS > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
