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
