- From: Glenn Maynard <glenn@zewt.org>
- Date: Fri, 4 Feb 2011 20:40:08 -0500
On Fri, Feb 4, 2011 at 6:43 PM, Ian Hickson <ian at hixie.ch> wrote: > My point is from a black-box perspective, one can never firmly say that > it's not just the browser being slow to start the thread. And we can't > disallow the browser from being slow. I don't think a black-box test suite can ever generally prove compliance against a dishonest vendor. > All workers should run soon, not maybe in the future. Not running a > worker should be an unusual circumstance. Errors that occur in unusual > circumstances aren't errors that authors will check for. > > This dicussion comes from Chrome having a very small limit currently. It > is my understanding that this limit is temporary and not representative > of what the API will be like once widely implemented. There will probably always be some limit, even if it's very high (eg. 1024). I think reasonable behavior when you exceed it is to throw an exception, but the spec seems to disallow this. Maybe that's why Chrome has the queueing behavior in the first place. Should there be a step early in 4.7.2/4.7.3 to permit browsers to throw an exception if the thread creation isn't allowed for any reason (without having any requirement to do so)? >> Non-looping 0ms timers are common, to run code when the current call >> finishes. > > Yeah, spec allows those fine. I should have said "non-recursive". That is, you can run a 0ms timer from another timer without causing recursion, but you'll receive the 4ms clamping unnecessarily. It might be possible to avoid this while still preventing 0ms looping timers from busy looping, but the spec prohibits that. (I could give an example of how this would happen, but I don't think it's important enough to go into further for now.) -- Glenn Maynard
Received on Friday, 4 February 2011 17:40:08 UTC