setImmediate

David Herman dherman at mozilla.com
Mon Aug 12 18:00:26 PDT 2013


On Aug 12, 2013, at 5:40 PM, François REMY <francois.remy.dev at outlook.com> wrote:

> I don't think of you as unimaginative, but I think there are other options.

:)

> Sure, there must be a way to "kill" a script that's burning your CPU but it doesn't have to be a dialog.

That's fine, I guess I didn't really mean dialog box was the only UI, just that killing the JS entirely is the only reasonable semantics I can imagine.

> Firstly, there's nothing really preventing a browser to perform a layout if it actually pauses the script, even if it may be hard to pause a thread while keeping all its pointer safe in an environment that's changed by another thread. But this is not impossible.

Not impossible to implement, but very bad. It would create new preemption semantics to shared state in JS, which is moooost of the time trying very hard to be strictly based on cooperative concurrency. Not only would injecting this preemption be a new potential source of very subtle bugs, it could be a security problem (run some slow script to force a new layout and use that as a bogus communication channel).

> Secondly, when a website becomes resource-intensive, you can display a "toolbar" saying 'This website looks to overuse your computer.' with a (stop the script) button that doesn't interrupt your experience (you can switch tab if you want, which will in return cause the tab to get way less system resources since he's in the background) or continue to use the website if it turns out it's just slow but not stuck in an infinite loop.

Sure-- again, playing with the UI isn't really what I meant. It's that semantically I see no alternative to a slow script but killing JS.

Dave




More information about the es-discuss mailing list