Re: [ScriptYielding] setImmediate clamping returns.

> If it's as simple as that, why don't we simply put DO NOT CLAMP in the
> spec for setTimeout/setInterval

Whether or not that's a dragon that *should* be slayed, it's not the dragon we're trying to slay here.

The primary difference: trying to fix an old established feature begets web compat questions (hell, who knows, there's probably idiots out there who rely on clamping to provide a reliable frequency cycle for their web app), whereas a new and relatively unimplemented (except, notably, IE10+) feature has no such baggage, and has a *chance* of avoiding the same fate.



> It seems to me like you are asking browser vendors to solve the halting problem.

I'm familiar with the halting problem from my CS degree. I can also read about it on wikipedia as can everyone else. I'm struggling to understand how you got that I was asking you to solve the halting problem?

I'm not asking you to determine if a loop is infinite or not. I am asking you to come up with other ways of dealing with a loop that's running too long, or too often, or too intrusively, or too whatever, for your [browser's] tastes.

One option is implementing it un-impeded (like IE apparently has), and wait for a problem, and then come up with a reasonable and limited solution at that time. I am not convinced that you will *have* to solve this problem. I think IE was smart for implementing it as they did and waiting to see. So that gets my vote. But my vote is irrelevant.

Another option is to fight against a feature "you" don't want by endlessly debating the supposed side-effects of supposed code that hasn't even been demonstrated to be a problem yet. That seems to have been the trend on every other discussion thread that setImmediate has been discussed on lately.

Perhaps you can tell my bias in that previous paragraph, that I don't think setImmediate() is necessarily setTimeout(..0) in sheep's clothing. We're in an entirely different web than we were 10 years ago. OS's expose system timers to browsers differently than they did back then. There's a whole new set of developer "best practices" and common idioms on the web. We have LOTS more (responsible) OSS libraries being written, and vetted by the community, than we did back then. And we have IMMENSELY intelligent developers with as much as 10 years more experience at solving "tough [browser] problems" than we did back then. We also have a much more competitive browser landscape now, so 

-----------------------

Regardless, when you do have to solve it, ONE solution is throttling via clamping. But that is not the only possible solution. Others have suggested an arbitrary threshold (you already established an arbitrary threshold of 4 nested calls) where you prompt, or you otherwise notify in the UI of a poorly performing tab by some icon in the tab/title-bar (like you do for playing video/audio), or you start skipping event turns in an exponential back-off, or…

It is a strawman argument to suggest that clamping is the only inevitable outcome of the feature, and no one wants that clamping, so therefore no one really wants this feature.




--Kyle

Received on Tuesday, 13 August 2013 01:02:13 UTC