[compositorworker] Avoid deadlock issue caused by importScript

[compositorworker] Avoid deadlock issue caused by importScript

importScripts is a sync API that runs on main thread. Using it on CW
will block the compositor thread on main which can lead to deallock in
the current Blink compositing architecture. So we should avoid it for
now.

TODO:
 - Find a way to throw if importScripts is used in CW. Current failure is
   subtle
 - Provide and alternative to synchronous importScripts. Note that async
   resource loading in already possible in workers thanks to fetch so we
   may be a able to leverage that.

BUG=624651
TEST=virtual/threaded/fast/compositorworker

Committed: https://crrev.com/ba9a8fbcce17e50e5006a008041301b934cde6f0
Cr-Commit-Position: refs/heads/master@{#403819}

[majidvp, 2016-07-05 18:15:30]

majidvp@chromium.org changed reviewers:
+ vollick@chromium.org

[Ian Vollick, 2016-07-05 18:31:30]

On 2016/07/05 18:15:31, majidvp wrote:

Sad, but lgtm.

[majidvp, 2016-07-05 18:36:25]

On 2016/07/05 18:31:30, vollick wrote:
> On 2016/07/05 18:15:31, majidvp wrote:
> 
> Sad, but lgtm.

Sad indeed. 

I think a workaround like this can be used by scripts
as a temp measure until we figure out the right solution.


function loadScriptAsync(url) {
  return fetch(url).then((response) => {
    return response.blob();
  }).then((blob) => {
    return self.importScripts(URL.createObjectURL(blob));
  });
}

[majidvp, 2016-07-05 18:38:02]

The CQ bit was checked by majidvp@chromium.org

[commit-bot: I haz the power, 2016-07-05 18:38:16]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-05 19:54:44]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-07-05 19:56:08]

Description was changed from

==========
[compositorworker] Avoid deadlock issue caused by importScript

importScripts is a sync API that runs on main thread. Using it on CW
will block the compositor thread on main which can lead to deallock in
the current Blink compositing architecture. So we should avoid it for
now.

TODO:
 - Find a way to throw if importScripts is used in CW. Current failure is
   subtle
 - Provide and alternative to synchronous importScripts. Note that async
   resource loading in already possible in workers thanks to fetch so we
   may be a able to leverage that.

BUG=624651
TEST=virtual/threaded/fast/compositorworker
==========

to

==========
[compositorworker] Avoid deadlock issue caused by importScript

importScripts is a sync API that runs on main thread. Using it on CW
will block the compositor thread on main which can lead to deallock in
the current Blink compositing architecture. So we should avoid it for
now.

TODO:
 - Find a way to throw if importScripts is used in CW. Current failure is
   subtle
 - Provide and alternative to synchronous importScripts. Note that async
   resource loading in already possible in workers thanks to fetch so we
   may be a able to leverage that.

BUG=624651
TEST=virtual/threaded/fast/compositorworker

Committed: https://crrev.com/ba9a8fbcce17e50e5006a008041301b934cde6f0
Cr-Commit-Position: refs/heads/master@{#403819}
==========

[commit-bot: I haz the power, 2016-07-05 19:56:09]

Patchset 1 (id:??) landed as
https://crrev.com/ba9a8fbcce17e50e5006a008041301b934cde6f0
Cr-Commit-Position: refs/heads/master@{#403819}

[jbroman, 2016-07-06 15:14:00]

https://codereview.chromium.org/2119383002/diff/1/third_party/WebKit/LayoutTe...
File
third_party/WebKit/LayoutTests/virtual/threaded/fast/compositorworker/resources/basic-plumbing-main-to-worker.js
(right):

https://codereview.chromium.org/2119383002/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/virtual/threaded/fast/compositorworker/resources/basic-plumbing-main-to-worker.js:21:
requestAnimationFrame(check);
ex-post-facto question: This looks like it will continue to
requestAnimationFrame even after it has resolved the promise (and try to resolve
it over and over again). Should this line be in an "else" clause?

[majidvp, 2016-07-06 17:45:38]

https://codereview.chromium.org/2119383002/diff/1/third_party/WebKit/LayoutTe...
File
third_party/WebKit/LayoutTests/virtual/threaded/fast/compositorworker/resources/basic-plumbing-main-to-worker.js
(right):

https://codereview.chromium.org/2119383002/diff/1/third_party/WebKit/LayoutTe...
third_party/WebKit/LayoutTests/virtual/threaded/fast/compositorworker/resources/basic-plumbing-main-to-worker.js:21:
requestAnimationFrame(check);
On 2016/07/06 15:14:00, jbroman wrote:
> ex-post-facto question: This looks like it will continue to
> requestAnimationFrame even after it has resolved the promise (and try to
resolve
> it over and over again). Should this line be in an "else" clause?

It definitely should!