[whatwg] Workers feedback

[Glenn Maynard]

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