Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Particular gotcha for accidentally and silently burning CPU cycles #9

Open
juj opened this issue Aug 4, 2016 · 3 comments
Open

Particular gotcha for accidentally and silently burning CPU cycles #9

juj opened this issue Aug 4, 2016 · 3 comments

Comments

@juj
Copy link

juj commented Aug 4, 2016

For a long time, I have been using core estimator as a polyfill and everything has been working smoothly. Recently, on a site I've been developing, I started getting really odd situations where the browser would continuously consume 100% of a single CPU core.

It turns out that I had misconfigured the installation of core estimator, and I had had the following code in my main .html file:

<html>
    ...
    <head>
        <script src='core-estimator/core-estimator.min.js'></script>
        <script src='core-estimator/workload.js'></script>
        ...
    </head>
    ...
</html>

This does not create any errors or warnings, and everything works, but the configuration mistake was that script workload.js was never intended to be included in the main html file. When it is included, it installs a self.onmessage handler to the top window, which postMessage(null)s to itself, causing workload.js to infinitely loop messages to itself the moment that anything else is postMessaged to the web page. This kind of error can easily go unseen, since it just silently burns CPU cycles on the background.

Perhaps workload.js could have checks in it before installing onmessage that the script context is actually inside a web worker, and if not, it would throw an exception "workload.js is not supposed to be included in main thread" or something similar? This would explicitly prevent such misconfigurations to silently turn into cycle wasting CPU busy spin loops.
@gevrum
Copy link

gevrum commented Aug 4, 2016 •
edited
Loading

Check performance in the context of Web Worker:

var isInWorker = ( typeof WorkerGlobalScope != 'undefined' ) && ( self instanceof WorkerGlobalScope );

if ( isInWorker ) {
    // use self and etc...   // under Worker
} else {
    // use window and etc...    // sim method onmessage   // under page
}

Just write your workload.js

@eligrey
Copy link
Member

eligrey commented Aug 4, 2016

Sure, I'll probably accept any well-formatted pullreq adding that.

@gevrum
Copy link

gevrum commented Aug 4, 2016

Ok, I will make soon

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@eligrey @juj @gevrum