Re: [Efficient Script Yielding] - Clamping

On Fri, Jul 1, 2011 at 3:27 PM, Jason Weber <jweber@microsoft.com> wrote:

>  ** **
>
> *Of course, we can't get all authors to write ideal javascript code.
> After all, we only had to add a clamp to setTimeout() and setInterval()
> because people were creating tight loops with timeouts and using 100% of
> available CPU (see https://bugzilla.mozilla.org/show_bug.cgi?id=123273,
> for example).  This new proposal provides another way for bad authors to
> recreate the problems that lead to the clamp being necessary for
> setTimeout()/setInterval() but it doesn't seem to allow any new use cases
> that a good author could achieve today.*
>
> ** **
>
> ** **
>
> I agree that in an ideal world we wouldn’t need to clamp setTimeout(0) to
> 4ms and could use that address this pattern rather than needing to add a new
> API. Between 1990 and 2009 setTimeout was implicitly clamped (by either the
> browser or the operating system) to at least 10ms on Mac OS X and Windows.
> When a developer wrote, debugged, and tested code on their machine using
> setTimeout(0) they would receive at most 100 callbacks a second. ****
>
> ** **
>
> This lead to a lot of incorrect assumptions. For example, on Windows
> setTimeout(0) would result in 64 callbacks a second which is ~60fps. That
> meant they could successfully use setTimeout(0) for script based animations
> which is of course a bug in the script but worked because of the underlying
> clamps. The previous clamps helped developers write a lot of buggy code that
> essentially ran at the refresh rate.
>
****
>
> ** **
>
> It’s challenging to change the implicit rules around a core API like
> setTimeout after 20 years with so much buggy code out there. That’s
> essentially what we’re doing by reducing the clamps to 4ms. If the legacy
> throttles hadn’t existed I doubt that we would need to clamp to
> setTimeout(0) which would make this discussion moot.****
>
> ** **
>
> We don’t believe that setImmediate should be clamped. Use agents need to
> remain responsive and prioritize work accordingly. We shouldn’t allow DOS
> scenarios and should be responsible citizens on the operating system.
> However, if a developer would like to use the entire core of a machine for
> computation on the UI thread and that webpage is in the foreground (implying
> user engagement) that should be allowed.****
>
> **
>

What makes you think that the authors who wrote buggy code with
setTimeout(0) loops will not write the same buggy code with setImmediate(),
thus forcing user agents to re-introduce a clamp?

- James