A client of WebKit might wish to interrupt JavaScript execution immediately instead of waiting for the usual timeout.
<rdar://problem/6912786>
Created attachment 30674 [details] Proposed patch
Comment on attachment 30674 [details] Proposed patch I believe the reason we originally called shouldInterruptScript only at the timeout was to avoid slowing down the engine with constant calls to the virtual function. I suppose that's why this new feature is opt-in. Geoff, what kind of testing would we do to see what effect this has on performance? The function name isStopping() doesn't seem specific to JavaScript, yet the behavior implemented is JavaScript-only.
(In reply to comment #3) > (From update of attachment 30674 [details] [review]) > I believe the reason we originally called shouldInterruptScript only at the > timeout was to avoid slowing down the engine with constant calls to the virtual > function. I suppose that's why this new feature is opt-in. Yes. Using this feature will induce two virtual calls at every timeout check, so it is opt-in. I am hoping that after merging this change I might be able to convert it to a single memory access in TimeoutChecker. > Geoff, what kind of testing would we do to see what effect this has on > performance? I could implement it in the Mac ChromeClient and run SunSpider in the browser before and after. However, the benefits of being able to stop JS from blocking the main thread sometimes outweigh raw JS performance. > The function name isStopping() doesn't seem specific to JavaScript, yet the > behavior implemented is JavaScript-only. The isStopping() ChromeClient call is used for one other purpose in our tree, immediately stopping HTML parsing on stopping a load. I could separate these two if you prefer; otherwise the isStopping() name matches isStopping() elsewhere, which means stopping a load.
> Geoff, what kind of testing would we do to see what effect this has on > performance? As long as there's an empty virtual function in the default client, we can test using SunSpider. Because we only make this call about twice every ten seconds, there's a good chance that it won't hurt performance too much. On the other hand, there's a good chance that it won't accomplish its goal, either.
This isn't exposed to WebKit clients, but workers already have a way to interrupt javascript execution (almost) immediately, see WorkerScriptController::forbidExecution().
The code that Alexey suggested gives a much better way of solving this problem. I'll close this bug and open a new one with a different patch some time in the future.
Comment on attachment 30674 [details] Proposed patch Clearing review flag to get this out of queue.