On Sun, Mar 20, 2011 at 6:19 PM, Wes Garland <[email protected]> wrote:
> > It doesn't, so we're going to need a non-clamping alias. Perhaps an
> [ugly] setTimeout ( ƒ, -1 ) ?
>
> I posit that the clamping behaviour and timer resolution are
> domain-specific (embedding-specific) implementation details. Browser makers
> have been able to deal with run-away CPU scripts, even the ES5 theoretically
> allows programs which consume all available CPU. Similarly, I'm sure they
> can manage to figure out how to clamp setTimeout() even if it isn't
> specified to have an explicit clamping behaviour.
>
> That said, I am personally more interested in a set of primitives which can
> be used to implement setTimeout, rather than setTimeout itself. Although,
> browser makers will probably have to clamp the primitives, too..
IIUC the only reason for the clamping requirement is due to code in the wild
that relies on that behavior from setTimeout. If you build setTimeout on a
lower-level primitive then clamping the primitive would be unnecessary,
functionally equivalent to rate-limiting while(1){}.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
