[whatwg] Workers: what should happen when exceeding worker limit?

[Ian Hickson]

On Thu, 23 Sep 2010, Ivan Kozik wrote:
>
> What should happen when instantiating a Worker that cannot be started 
> because of the limit on the number of workers?

That's a hardware limitation, and as such is something we tend to leave up 
to the user agents. In practice, it's often the case that user agents are 
very constrained in how they can deal with hardware limitations (e.g. if 
the user agent cannot allocate more memory, then it might not be able to 
allocate memory to fire an exception, or to keep track of the worker to 
run it later), and therefore we tend to leave that open. So long as the 
limitations are big enough that most pages don't run into them, it doesn't 
really matter -- a user agent with a compatibility issue can almost 
always just increase the limits if pages would otherwise break!


> Chrome 6 and Chromium 7.0.532.0 (60255) put the 17th worker in a queue, 
> to be created when some existing worker terminates.  This queue seems to 
> be limitless in size (or at least it is large).  In Opera 10.70 (9049), 
> instantiating the 17th Worker throws "Error: QUOTA_EXCEEDED_ERR".

I guess the simplest answer is "don't use more than 16 workers". There's 
really not much point in doing so anyway, since most systems don't have 16 
cores today. (This will naturally change in the future, but then so will 
the limits.)


> I'd much prefer that it failed immediately, rather than being put in a 
> queue.

Unfortunately we can't really require immediate failure, since there'd be 
no way to test it or to prove that it wasn't implemented -- a user agent 
could always just say "oh, it's just that we take a long time to launch 
the worker sometimes". (Performance can be another hardware limitation.)


> I use a SharedWorker as an enhancement, and I don't want to implement a 
> timeout for the Worker spawning (I'd rather have it fail, so that I can 
> immediately do something else).  I can avoid spawning more than 16 
> workers, but I never know if another tab has already created enough 
> workers to exhaust the global worker limit (64 in Chrome, ~118 in 
> Opera).  And if I really want to spawn the worker, I can always try 
> spawning it again soon.

If you have performance constraints, then you should just use timeouts to 
test whether the worker started -- that way you'll do the worker-less 
fallback behaviour regardless of whether the timeout fired because workers 
are just slow on the user's computer or because there are no more worker 
slots available.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'