[webkit-dev] setTimeout as browser speed throttle

Maciej Stachowiak mjs at apple.com
Wed Oct 1 02:34:25 PDT 2008

On Oct 1, 2008, at 1:24 AM, David Hyatt wrote:

> On Oct 1, 2008, at 2:52 AM, Darin Fisher wrote:
>> I can appreciate that you aren't interested in revisiting this  
>> problem after having resolved it finally by adding the clamp.  I  
>> believe you when you say you had compelling evidence too.
> We are interested in revisiting the problem or we wouldn't be  
> suggesting a new high resolution timer API.

I'm with Hyatt. The reason we are having this thread is precisely to  
revisit the problem.

> I don't know how clear I was in the previous email, but basically it  
> can take a lot of time before you see problems.  What happens is a  
> site makes a change, screws up and puts in an unintentional  
> setTimeout loop, and then they pwn the CPU of a browser with no  
> clamp.  They don't discover it because every browser has a pretty  
> high clamp.  When we had these issues, they'd basically crop up one  
> site at a time every so often.  The good news is that usually the  
> sites would fix the problems, but the bad news is it could take a  
> while, and angry users would be switching to Firefox.

That is what I was alluding to when I said it took us 3.5 years to  
first realize we had to add the clamp. The problems come and go, but  
they are consistently a problem, and it can take a while to realize it.

However, the bug Mike cited seems to mention problems with the 1ms  
limit on some real sites: <http://code.google.com/p/chromium/issues/detail?id=792 
 >. At least 5 sites are mentioned, including nytimes.

I think we are converging on some good solutions (somewhat lower basic  
clamp, new highres API) and I regret if this thread has felt hostile  
to anyone.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20081001/40897f4a/attachment-0001.html 

More information about the webkit-dev mailing list